CloudBeaver proxy header authentication must fail closed
CloudBeaver is a web-based database management server. Its documentation covers local accounts, LDAP, SAML, OpenID, JWT, AWS IAM, reverse proxy header authentication, API tokens, and anonymous access. The breadth is useful for enterprises, but it makes authentication configuration the most important part of the deployment. A database console that trusts the wrong header can turn an ordinary HTTP request into an administrator session.
The reverse proxy header method is particularly sensitive. CloudBeaver's documentation warns that if users can reach CloudBeaver directly or send the headers themselves, they can authenticate as another user. The proxy must strip client-supplied identity headers, set its own trusted values, and prevent direct access to the backend. A network rule or firewall is part of the authentication design, not an optional deployment detail.
Measure without overclaiming
On 2026-11-06 at 03:47:15 +08:00, a count-only ZoomEye query for title="CloudBeaver" with sub_type=all, page 1, and page size 1 returned 1,592 matches. The app="CloudBeaver" query returned zero. A title match may identify a login page, documentation, or an unrelated page. The count does not confirm that any instance is unauthenticated or trusts a header.
Use the result to prioritize an inventory of owned database consoles. Check whether CloudBeaver is reachable only through the approved proxy, whether anonymous access is disabled, and which authentication method is active. Do not probe a public database console with guessed headers or credentials.
Remove direct paths to the backend
Bind CloudBeaver to a private interface or a Unix socket that only the proxy can reach. Use firewall rules and container network policy to block direct connections from users and from other workloads that do not need access. The proxy should overwrite, not append, identity headers. It should reject requests that contain protected header names from the client before it adds trusted values.
Test the path from three places: through the proxy with a valid identity, through the proxy without an identity, and directly to the CloudBeaver port. The last test should fail before the application authenticates anyone. Then send a forged header from a client that can reach the proxy and confirm the proxy removes it.
Choose authentication modes deliberately
Anonymous access is useful for a deliberately public read-only deployment, but it should not be enabled by default on a database console. Local accounts need password policy, lockout, and recovery controls. LDAP, SAML, OpenID, and JWT integrations need issuer, audience, certificate, and group mapping validation. AWS IAM authentication should be tested with the intended role and the actual database connection path.
API tokens are separate from browser sessions. The documentation says each user creates their own tokens and that token creation can be enabled in server configuration. A token should inherit the user's permissions, be limited in number, and be revoked when a job ends. Do not use an administrator token for an integration that only reads one database.
Separate connection authority from console authority
CloudBeaver can store database credentials and open connections. A user who can administer the console but should not use a production database needs a separate policy. Examine saved credentials, shared connections, connection templates, and team permissions. A connection that uses a privileged database account is more dangerous than the console role alone suggests.
Prefer per-team database accounts and connection policies. Restrict who can save or reveal credentials. Test whether a user can connect to a database that is not assigned to their team. If pass-through authentication is enabled, confirm that the database identity and the console identity are both authorized for the requested action.
Monitor authentication and SQL activity
Log sign-in method, proxy identity, user, team, database connection, and request result without logging SQL text that contains secrets. Alert on direct backend access attempts, forged header patterns, anonymous sessions, token creation, failed logins, and a user connecting to an unfamiliar database. CloudBeaver can also record API requests when auditing is enabled, but the application and proxy logs should agree on the identity.
Test failure and recovery
Disable the identity provider and confirm that the console fails closed. Break the proxy header mapping and confirm that users are denied rather than mapped to a default account. Revoke an API token and confirm that it stops working. Restore a backup in isolation and verify that saved connections do not automatically reach production.
CloudBeaver is a useful database gateway because it combines many authentication methods with a broad SQL surface. The reverse proxy mode is safe only when the backend cannot be reached directly and the proxy controls identity headers. The title count is a discovery signal. The authentication path and database authorization model are the controls that matter.
