Supabase Releases Security & compliance

SSL not enforced

Part of the Database DR & network check

What it is

SSL is not enforced for database connections, so clients may connect without TLS.

Why it matters

The connection carries your credentials and your data in plaintext to anyone positioned on the network path. Enforcement is the only way to know that every client is actually using TLS rather than merely being able to.

Check what your connections do today

Ask Postgres directly — this shows whether the connection you are on, and every other live one, negotiated TLS:

-- your current connection SELECT ssl, version, cipher FROM pg_stat_ssl WHERE pid = pg_backend_pid(); -- every client connected right now SELECT s.pid, a.usename, a.client_addr, s.ssl, s.version FROM pg_stat_ssl s JOIN pg_stat_activity a USING (pid) WHERE a.client_addr IS NOT NULL;

Any row with ssl = f is a client currently sending credentials and data in plaintext — and the one that will break when enforcement turns on. Fix those clients first.

What “not enforced” actually means

Supabase supports TLS on every connection, but supporting it is not requiring it. Until Enforce SSL on incoming connections is on, a client that omits sslmode — or sets sslmode=disable because a copied snippet did — connects happily in plaintext. Enforcement is the only setting that turns “every client could use TLS” into “every client does”.

The error a plaintext client gets afterwards

Once enforcement is on, a non-TLS client is refused with the canonical Postgres rejection — if this shows up in your logs after enabling, it is pointing at the client you missed:

FATAL: no pg_hba.conf entry for host "203.0.113.7", user "postgres", database "postgres", no encryption

Enable it manually

Dashboard → Project Settings → Database → Enforce SSL on incoming connections, or via the Management API:

curl -X PATCH "https://api.supabase.com/v1/projects/$PROJECT_REF/ssl-enforcement" \ -H "Authorization: Bearer $SUPABASE_ACCESS_TOKEN" \ -H "Content-Type: application/json" \ -d '{"requestedConfig": {"database": true}}' # then, in every client postgresql://…?sslmode=require # minimum postgresql://…?sslmode=verify-full # also pins the server identity — use with the Supabase CA cert

For verify-full, download the project’s CA certificate from the same Database settings page and point the client at it (sslrootcert=). That upgrade closes the remaining gap this page’s sibling check — TLS verification disabled — is about.

How lumioguard fixes it

The scan reads the project’s enforcement state and cross-references every connection string in the repo, so the finding arrives with the list of clients that would break. The fix is a prepared change you approve: enforcement on, plus the sslmode updates for each client that needs one.

Run them all on your app

Connect your repo and your live services with read-only scopes. The first scan is free, and nothing changes without your approval.