Is port 5432 (PostgreSQL) exposed to the internet, and is pg_hba.conf too loose?

Why PostgreSQL starts out safe, and what changes that

IANA registers port 5432 for PostgreSQL. PostgreSQL’s own connections and authentication documentation confirms that listen_addresses defaults to localhost — a fresh installation simply doesn’t accept network connections from anywhere else until an administrator deliberately widens it, typically to * or a specific public interface, to allow remote application servers to connect. That change alone doesn’t make a database insecure; PostgreSQL still requires a second file, pg_hba.conf, to authorize who can authenticate and how.

Where the risk actually comes from

PostgreSQL’s own pg_hba.conf documentation describes it as a list of rules evaluated top to bottom, with the first matching rule deciding whether a connection is accepted and which authentication method it must use. The risk shows up when listen_addresses is widened to accept connections from anywhere, and a pg_hba.conf rule is also set broadly — for example allowing all hosts with the trust method, which accepts any connection without checking a password at all. That combination, often introduced temporarily during development or initial setup and then never tightened before the server goes into production, is what turns a reachable port 5432 into an open door rather than just an open port. Even with a real password method configured, an internet-facing PostgreSQL port is routinely targeted for credential brute-forcing and password spraying against default accounts like postgres.

How to check your own exposure

AdminKit’s planned open ports check is designed to test whether port 5432 and other commonly-exposed database ports on your own public IP respond from outside your network — a useful way to confirm listen_addresses is actually scoped the way you expect, rather than relying on memory of a configuration change made months earlier.

How to fix it

• Set listen_addresses to a specific private network interface rather than a wildcard, so the database process itself never binds to a publicly routable address unless that’s genuinely required.
• Replace any trust or unrestricted pg_hba.conf rule with scram-sha-256 authentication, scoped to the specific source IP ranges that need access — not 0.0.0.0/0.
• Add a firewall rule restricting port 5432 to the application servers and administrators that actually need it, as defense in depth beyond pg_hba.conf alone.
• If remote administrative access is genuinely needed, prefer connecting over a VPN or SSH tunnel rather than exposing 5432 directly to the internet.

Defensive use only

Every check this page links to is for assets you own or are explicitly authorized to test. Never scan, probe, or attempt to connect to a network or device you don’t control — AdminKit’s active checks only ever run against the IP making the request or an asset you’ve verified ownership of. See our Disclaimer and Acceptable Use Policy for the full terms.