pgAdmin is both a desktop application and a web application. The server mode is the deployment shape that changes the security question. Users must log in, an initial superuser is created, and file storage is scoped to each user under the configured storage directory. A public pgAdmin page therefore represents an authentication surface, not a direct database endpoint.
Start with server mode
pgAdmin documentation says server mode has been the default since version 2. A server-mode deployment can run behind a reverse proxy or through a WSGI interface. Users authenticate before using pgAdmin, and the initial administrator can add superusers and non-superusers. Desktop mode does not require this web login model because each user runs a local instance.
The distinction matters during inventory. A pgAdmin title may belong to a local desktop session exposed by mistake, a server deployment, or a documentation page. Review the deployment mode before applying controls designed for a shared web service.
A bounded ZoomEye observation
On 2026-10-31, app="pgAdmin" returned 0 matches and title="pgAdmin" returned 47757. Both queries used page 1, page size 1, and sub_type=all. The zero app result is valid for that query, not a failed request. The title count is broad and should be treated as a discovery lead rather than the number of unprotected servers.
A title can appear on login pages, documentation, and other pages that mention pgAdmin. The observation does not show whether the deployment is in server mode, whether login succeeds, or which database servers are registered. Those facts require owner verification.
Treat proxy identity as a security boundary
pgAdmin supports webserver authentication behind a reverse proxy. The documentation warns that the reverse proxy must overwrite the relevant header and that header-asserted identity is restricted to configured trusted proxies. A proxy that passes a client-controlled header can let an attacker choose an identity. Verify the full chain from the browser to pgAdmin, not just the proxy's static configuration.
Set ALLOWED_HOSTS for the known hostnames where the deployment supports it. The configuration documentation warns that an empty value can accept all IPs and leave the application open to Host Header Injection. Validate redirects and password-reset links against the same allowed hosts. A reverse proxy should reject direct access to the application listener.
Review login controls
Enable account lockout and rate limiting on the login endpoint. pgAdmin's internal authentication source supports MAX_LOGIN_ATTEMPTS, while external authentication sources may need rate limiting at the reverse proxy or identity provider. Use two-factor authentication where the deployment and policy require it.
The initial superuser should not remain a shared account. Review every pgAdmin user, its authentication source, and the database servers it can reach. A pgAdmin login that can open a stored server definition may have access to a database credential even if the pgAdmin account itself is not a database superuser.
Test the exposed path
From an untrusted network, request the login page and a protected page. Try a spoofed proxy identity header, a disallowed Host header, and the login endpoint without credentials. Each should fail safely. From an approved network, log in with a low-privilege account and verify that it cannot administer users or reach servers outside its authorization.
ZoomEye can help find pgAdmin-like pages for an asset inventory. The response decision depends on the actual deployment mode, proxy header handling, user roles, and database registrations. Keep those layers separate in the report.