Why You Should Never Use trust in PostgreSQL

Why You Should Never Use trust in PostgreSQL

If you have ever managed a PostgreSQL instance, you’ve likely encountered the infamous pg_hba.conf file. It’s the bouncer of your database, deciding who gets in and who stays out.

But there’s a specific setting in this file that acts like leaving the keys in the lock of your front door with a sign that says, Come on in That setting is called trust.

The Quick Fix Trap

We’ve all been there. You’re deploying a new app, or a developer is struggling to connect, and you keep seeing that frustrating error: FATAL: password authentication failed for user frogge

After thirty minutes of troubleshooting .pgpass files and environment variables, someone suggests the magic fix:

Just change the authentication method to trust in pg_hba.conf. It’ll work instantly.

And it does. The connection works, the app starts, and everyone is happy. But you’ve just traded your long-term security for a five-minute convenience.

What Does trust Actually Mean?

In PostgreSQL terminology, trust is not an authentication method—it is the absence of authentication.

When you define a rule like this: host all all 10.10.10.0/24 trust

You are telling your server: Anyone coming from the 10.10.10.x network is my best friend. Don’t ask them for a password, don’t verify their identity. Just give them full access to everything.

The Myth of the Secure Internal Network

The most common excuse for using trust is: It's fine, our internal network is private. No hackers can get in here.

This is a dangerous assumption. Modern cybersecurity operates on the principle of Zero Trust for a reason. If a single device on your network — a printer, a workstation, or even a smart coffee machine — is compromised, the attacker is now inside. Since your database trusts the entire network, the attacker has a VIP pass to your most sensitive data without ever needing a password.

A Better Way: Security by Default

Instead of taking the easy way out, you should implement layers of security that protect your data even if your network is breached.

1. Use SCRAM-SHA-256: This is the modern standard for password-based authentication in Postgres. It’s secure, robust, and prevents password sniffing.
2. Enforce SSL: Use hostssl instead of host to ensure that data moving between your app and the database is encrypted and cannot be intercepted.
3. The Principle of Least Privilege: Never use all all. Specify exactly which user can connect to which database from which specific IP address.

A secure entry should look like this: hostssl mydb myuser 10.10.10.29/32 scram-sha-256

Final Thoughts

Security is often a tug-of-war between convenience and safety. While trust might save you a few minutes of configuration today, it could cost you your entire database tomorrow.

In a production environment, trust is never the answer. Treat your database like a vault, not a revolving door. Your future self (and your users' data) will thank you.