PostgreSQL / Supabase security intelligence

You vibe coded the app.
Who audited the database?

DBX reconstructs how your database can actually be reached — across RLS policies, grants, functions, storage, relationships, and tenant boundaries.

Zero credentials • Deterministic engine • Explainable findings

snapshot 04:12z
unauthenticatedEXECUTE → PUBLICelevatedrls bypassedfk: customer_idANONYMOUS USERROLE: ANONPUBLIC APIPOSTGREST / REST V1profilesRLS ENFORCEDordersRLS ENFORCEDRPC FUNCTIONGET_CUSTOMER_DOCUMENT()SECURITY DEFINERSEARCH_PATH MUTABLECUSTOMERS18,291 ROWSCUSTOMER_DOCUMENTSSTORAGE.OBJECTS →audit_logAPPEND ONLY
evaluating reachability…
43/100

database security

4 CRITICAL7 HIGH11 MEDIUM

engine

We don't check your code.
We check what your database actually allows.

Migrations describe intent. Permissions describe reality. DBX introspects the live security objects — policies, grants, routines, buckets, relationships — and resolves what each identity can reach in practice.

47
tables introspected
83
policies parsed
112
grants resolved
91
relationships traced
read-only
█

deterministic findings

Every verdict arrives with its evidence.

CRITICAL

Anonymous users may reach customer documents

attack path

  1. ANON
  2. PUBLIC RPC
  3. SECURITY DEFINER
  4. CUSTOMER_DOCUMENTS
affected
18,291 potential records
evidence
public.get_customer_document(uuid)
reason
Function executes with elevated database privileges and does not enforce tenant ownership before returning the requested object.
HIGH

Tenant boundary not enforced on invoice documents

attack path

  1. AUTHENTICATED
  2. INVOICES
  3. INVOICE_DOCUMENTS
  4. STORAGE.OBJECTS
affected
6,402 potential records
evidence
policy invoice_documents_select ON public.invoice_documents
reason
The policy predicate filters on invoice_id alone. The relationship to the owning tenant is never evaluated, so any authenticated caller holding an invoice id can read the object.

database x-ray

Nine surfaces. One verdict each.

The scanner decomposes the database into the surfaces an attacker actually traverses, then reports what each one currently permits.

AUTH2 WARNINGSRLS12 ISSUESTABLES47 MAPPEDFUNCTIONS3 DANGEROUSSTORAGE1 EXPOSEDGRANTS6 EXCESSIVETENANT ISOLATIONFAILEDRELATIONSHIPS91 TRACEDINDEXESCLEANDATABASEPOSTGRES 15.6

path analysis

Findings are useful.
Attack paths are better.

A weak policy may look harmless by itself. DBX connects individual weaknesses to determine whether they form a usable path through your database.

attack path
5 hops
severity
critical
confidence
high
no sessionEXECUTE → PUBLICdeniedruns as ownerrls bypassedobject_idsigned readINTERNETUNTRUSTEDANONROLE: ANONAPIREST + RPCCUSTOMERSTABLERPCGET_CUSTOMER_DOCUMENT()RLS BLOCKPOLICY ENFORCEDSECURITY DEFINERELEVATED PRIVILEGESDOCUMENTSCUSTOMER_DOCUMENTSSTORAGESTORAGE.OBJECTSCUSTOMER FILEOBJECT REACHABLE

posture

43

Database security score

The score is a function of the findings, not an opinion. Every point deducted maps to a specific rule, a specific object, and the evidence that triggered it.

RLS
31
Tenant isolation
22
Function security
58
Permissions
71
Storage
64
Data integrity
89

remediation

Don't just find it.
Fix it.

Each deterministic finding carries a proposed migration tied to the exact object that produced it, with the expected security effect and the compatibility risk stated up front. Nothing is applied to your database for you.

current
1create policy "documents_select"
2on public.customer_documents
3for select
4to anon, authenticated
5using (true);
6
7create function public.get_customer_document(doc uuid)
8returns setof customer_documents
9language sql
10security definer
11as $$
12 select * from customer_documents
13 where id = doc;
14$$;
remediated
1create policy "documents_select"
2on public.customer_documents
3for select
4to authenticated
5using (
6 tenant_id = (select auth.jwt() ->> 'tenant_id')::uuid
7);
8
9create function public.get_customer_document(doc uuid)
10returns setof customer_documents
11language sql
12security invoker
13set search_path = public
14as $$
15 select * from customer_documents
16 where id = doc;
17$$;

zero credentials

We don't want
your database password.

  1. 01

    Your database

    you run the introspection

  2. 02

    Read-only introspection

    catalog metadata only

  3. 03

    Security snapshot

    no rows, no data

  4. 04

    DBX

    snapshot in, findings out

  5. 05

    Deterministic analysis

    rules over evidence

No database password

No persistent connection

No agent

No production write access

The snapshot contains catalog metadata — schemas, policies, grants, routines, relationships. It never contains your rows. If the snapshot leaked, an attacker would learn what you already publish in your migrations.

Read the methodology

You vibe coded
the app.

Who audited
the database?

AI can generate PostgreSQL policies in seconds. That doesn't mean those policies actually isolate your customers.

vibe checked

Loved by developers who ship fast.

“If you're a vibe coder, keep this in your toolbox. This is a MUST HAVE. I built my whole backend with AI, but DBX found three RLS leaks I never would have seen.”

AR

Alex Rivera

Founding Engineer @ VibeFlow

“The security audit for the rest of us. It's deterministic, fast, and didn't ask for my production password once. Absolute magic.”

SC

Sarah Chen

Fullstack Developer @ NeonPulse

“DBX is a MUST HAVE for any serious Supabase project. We use it before every major deployment to ensure our tenant boundaries are actually solid.”

JS

Jordan Smith

CTO @ Supastack

“Most security tools are too noisy. DBX is quiet until it finds something that actually matters. The attack paths are a game changer for explaining risk to stakeholders.”

ER

Elena Rodriguez

Lead Architect @ DataGrid

“I vibe coded my MVP in a weekend. DBX audited it in 30 seconds. Found a critical bypass in my public RPCs. Probably saved my startup.”

MT

Marcus Thorne

Indie Hacker @ SoloBuild

“Zero data retention and zero credentials? This is how security tools should be built. It introspects the catalog and leaves. Brilliant.”

LV

Lila Vance

DevOps Engineer @ CloudScale

“If you're a vibe coder, keep this in your toolbox. This is a MUST HAVE. I built my whole backend with AI, but DBX found three RLS leaks I never would have seen.”

AR

Alex Rivera

Founding Engineer @ VibeFlow

“The security audit for the rest of us. It's deterministic, fast, and didn't ask for my production password once. Absolute magic.”

SC

Sarah Chen

Fullstack Developer @ NeonPulse

“DBX is a MUST HAVE for any serious Supabase project. We use it before every major deployment to ensure our tenant boundaries are actually solid.”

JS

Jordan Smith

CTO @ Supastack

“Most security tools are too noisy. DBX is quiet until it finds something that actually matters. The attack paths are a game changer for explaining risk to stakeholders.”

ER

Elena Rodriguez

Lead Architect @ DataGrid

“I vibe coded my MVP in a weekend. DBX audited it in 30 seconds. Found a critical bypass in my public RPCs. Probably saved my startup.”

MT

Marcus Thorne

Indie Hacker @ SoloBuild

“Zero data retention and zero credentials? This is how security tools should be built. It introspects the catalog and leaves. Brilliant.”

LV

Lila Vance

DevOps Engineer @ CloudScale

pricing

Pay per audit. No subscriptions.

We don't want to be another monthly SaaS subscription. Scan your database, get the facts, fix your vulnerabilities, and move on.

Your database never reaches our servers.

DBXray analyzes your snapshot locally in your browser. We don't retain your schema, findings, or remediation data.

Save your remediation SQL before closing the tab.

Database Scan

$0

Free Unlimited Introspection

  • Introspect unlimited schemas
  • View database topology & score
  • See finding counts and severity
  • Local analysis (data never leaves browser)
Most Popular
one-time

Full Remediation

$19 / 5 scan audits

Introductory Launch Price
  • Includes 5 unique scans
  • Unlock exact vulnerability details
  • Complete attack path graphs
  • Copy-paste SQL remediation
  • Verify fixes after remediation

Can someone reach something in your database that they shouldn't?

Run a read-only introspection and get an evidence-backed answer in under a minute.