Starting with Zabbix 7.2, support for passing API authentication credentials through the JSON-RPC auth property was removed as part of ZBXNEXT-9452.

This introduced a functional regression for deployments where access to the Zabbix HTTP endpoint is additionally protected by HTTP Basic Authentication at a load balancer or reverse proxy.

In such deployments, two independent authentication layers are intentionally used:

1. The load balancer or reverse proxy validates HTTP Basic credentials before allowing the request to reach the Zabbix frontend.
2. Zabbix validates a separate API session or API token and applies application-level roles and permissions.

Before the removal of the JSON-RPC auth property, these mechanisms could coexist because they used different parts of the request:

{{{}POST /api_jsonrpc.php HTTP/1.1
Authorization: Basic <reverse-proxy-credentials>
Content-Type: application/json-rpc{}}}{{{}

{ "jsonrpc": "2.0", "method": "host.get", "params": \{ "output": "extend" }

,
"auth": "<zabbix-api-token>",
"id": 1
}{}}}

The HTTP Authorization header was consumed by the reverse proxy, while the JSON-RPC auth property was independently processed by Zabbix.

Starting with Zabbix 7.2, Zabbix API authentication requires:

Authorization: Bearer <zabbix-api-token>

This conflicts with the existing reverse-proxy authentication requirement:

Authorization: Basic <reverse-proxy-credentials>

Both mechanisms require exclusive use of the same HTTP header. A client cannot reliably provide separate Basic and Bearer credentials for two different authentication layers in a single request.

As a result, upgrading to Zabbix 7.2 removes the ability to combine reverse-proxy HTTP Basic Authentication with Zabbix API authentication.

Security impact

These authentication layers protect different security boundaries:

• The reverse proxy prevents clients without the perimeter credential from reaching the Zabbix application.
• Zabbix API authentication identifies the API user and enforces application-level roles and permissions.
• A compromised Zabbix API token is insufficient without the reverse-proxy credential.
• A compromised reverse-proxy credential does not grant any permissions within Zabbix.
• Both credentials can be rotated, audited and restricted independently.

This is not necessarily multi-factor authentication in the strict sense, but it provides two independent authentication gates.

Expected behavior

Zabbix should provide a supported API authentication mechanism that does not require exclusive ownership of the standard HTTP Authorization header.

One possible solution would be to accept an additional application-specific header:

Authorization: Basic <reverse-proxy-credentials>
X-Zabbix-Authorization: Bearer <zabbix-api-token>

The existing standard mechanism should remain supported:

Authorization: Bearer <zabbix-api-token>

Restoring the deprecated JSON-RPC auth property is not necessarily required. A dedicated Zabbix API authentication header would preserve separation between authentication metadata and the JSON-RPC payload while restoring support for layered authentication.

Actual behavior

When the endpoint is protected by HTTP Basic Authentication, the Bearer token cannot be delivered to Zabbix. The request either fails at the reverse proxy or reaches Zabbix without valid API credentials and returns:

Invalid params: Not authorized

References

• ZBXNEXT-9452: Remove the deprecated API features from 7.2
• ZBXNEXT-7066: API auth through header