Database access and authentication misconfiguration¶

A database can be exposed by broad network access, authentication bypasses, excessive role privileges or missing transport verification. Encryption at rest does not compensate for an account that can read every table. This guide uses PostgreSQL pg_hba.conf to illustrate connection-policy review; it is not a complete database configuration.

Restrict who may connect¶

The address below is reserved for documentation. Replace it with the specific, approved application source address in your environment.

Unsafe for an application database: trust any IPv4 client.

host    all    all    0.0.0.0/0    trust

Safer example: allow one role and database over TLS, then deny other TCP access.

hostssl    appdb    app_user    192.0.2.10/32    scram-sha-256
host       all      all         0.0.0.0/0       reject
host       all      all         ::/0            reject

PostgreSQL uses the first matching record. Remove or narrow earlier permissive entries; adding these lines after an existing broad allow rule does not fix it. The pg_hba.conf reference documents matching and authentication methods. Preserve separately reviewed administration, replication and local-socket access rather than replacing an entire production file with this fragment.

Enable and configure server TLS, provision a compatible SCRAM password, and ensure the client validates the certificate and hostname. For libpq clients, review sslmode=verify-full and the required trust configuration in the PostgreSQL SSL documentation. A hostssl rule alone does not configure certificates or validate the server on the client's behalf.

Check the policy¶

In a disposable environment, confirm the intended application connection succeeds, a different role or source is denied, and a non-TLS connection is rejected. Test a certificate hostname mismatch separately. Inspect effective rules and their parse errors before a controlled reload; retain a tested recovery path for administration.

Limit the application role's table privileges, keep it non-superuser, restrict backups and protect credentials outside source. Continue with hardcoded passwords, TLS certificate validation and SQL injection.

Treat a database setting as a context-dependent finding. Verify the effective network and role policy; a single configuration line does not establish either exploitation or complete protection.