The trust method in pg_hba.conf allows a connection unconditionally. Anyone who can reach the server can log in as any PostgreSQL user they choose, with no password. Use it only on isolated throwaway setups. For real data, use scram-sha-256 on every record that can be reached over a network.
What the documentation says
The PostgreSQL reference for pg_hba.conf describes trust plainly: it allows the connection unconditionally, so anyone who can connect can log in as any PostgreSQL user they wish, without a password or any other authentication. That includes the superuser role.
Trust shows up in tutorials and Docker examples because it removes friction. It is also easy to leave behind when a local test configuration is copied into an environment that other machines can reach.
The methods you will compare
| Method | What it does | Use it when |
|---|---|---|
| trust | No authentication | Isolated local testing only |
| reject | Refuses the connection | Blocking specific hosts |
| scram-sha-256 | Verifies the password with SCRAM-SHA-256 | Default choice for password logins |
| md5 | SCRAM-SHA-256 or MD5 verification | Legacy clients, being phased out |
| password | Sends the password in clear text | Not on untrusted networks |
The md5 entry carries a warning in the documentation. Support for MD5 encrypted passwords is deprecated and will be removed in a future release. If you still have MD5 hashes stored, see migrating PostgreSQL MD5 passwords to SCRAM.
The password method is worth a note too. The docs say the password is sent in clear text over the network, so it should not be used on untrusted networks.
How to find trust in your setup
- Open pg_hba.conf and search for the word trust.
- Check each match for its connection type. A local line limits exposure to people on the host. A host line may expose the network.
- Read the address range. A narrow range is a smaller problem than a wide one, but still unauthenticated.
- Check container images and compose files, including any custom configuration they mount.
- Replace with scram-sha-256, set a strong password for the role, and reload the configuration.
- Test from a second machine that a login without the password fails.
Remember that order matters. Our post on how first match works shows how an early permissive line overrides a later strict one.
A dev container is still a risk
A common pattern is a development database with trust enabled and a published port. If that port binds to all interfaces, a person on the same network can connect with no password. See Docker Compose and published database ports for how to keep it on loopback.
When trust is acceptable
A local Unix socket on a single user machine, or an ephemeral database inside a test run that holds no real data, are the realistic cases. Even then, never copy that file into a shared environment.
Safeguard's dependency scanning and policy gates can run on the repositories that hold your container and compose files. A free scan is at gold.safeguard.sh/scan.
Quick check
Does trust skip the password for the superuser too?
Yes. The documentation says anyone who can connect can log in as any PostgreSQL user they wish.
Is scram-sha-256 the replacement?
It is the usual password method. The docs mark md5 as deprecated.
Is local trust safe?
It narrows exposure to users on the host but still skips authentication. Treat it as a testing convenience.
Sources
Last reviewed: 19 October 2026.
