Network open to 0.0.0.0/0
Part of the Database DR & network check
What it is
The database network restrictions allow connections from 0.0.0.0/0 — any address on the internet.
Why it matters
Your database is directly reachable from anywhere, so the credential is the only control. That places it in the path of every credential-stuffing and scanning campaign on the internet.
What “network restrictions” are
Supabase’s network restrictions are an IP allowlist in front of your Postgres — direct connections and the connection pooler both. The default is 0.0.0.0/0: any address on the internet may attempt to connect and present credentials. The setting lives at Project Settings → Database → Network Restrictions. Note the scope: it protects the *database ports*. Requests through the Data API (PostgREST) authenticate with keys and RLS and are not governed by this list.
Why an open database matters even with a strong password
An internet-reachable Postgres port collects credential-stuffing and brute-force traffic as a matter of course, and it turns every leaked connection string — a log line, a CI artifact, a laptop — into immediate access from anywhere. An allowlist converts “leaked credentials” from an incident into a non-event initiated from an unapproved network.
Add restrictions without locking yourself out
Order matters: add the ranges you connect from before removing the open rule.
# 1. collect what actually connects: your office/home IP, CI runners,
# servers with static egress. (check current sessions:)
select distinct client_addr from pg_stat_activity where client_addr is not null;
# 2. add each as a CIDR in Project Settings → Database → Network Restrictions
# (or via the Management API)
curl -X POST "https://api.supabase.com/v1/projects/$PROJECT_REF/network-restrictions" \
-H "Authorization: Bearer $SUPABASE_ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-d '{"dbAllowedCidrs": ["203.0.113.7/32", "198.51.100.0/24"]}'The honest caveat: default serverless runtimes (Vercel functions and similar) have no stable egress IP, so they cannot be allowlisted directly — route them through the platform’s static-egress option, or accept that those paths use the Data API while the allowlist protects direct database access: psql sessions, migrations, dashboards, anything long-lived.
How lumioguard fixes it
The scan reads the restriction list on every run and pairs it with where your app actually connects from. The finding arrives with the observed client addresses, so the prepared change you approve is an allowlist built from reality rather than guesswork.
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.