Skip to content
Code Recycle

Component · for humans & their agents

Public Database Check

verified · first-partyactively maintained$0 during beta (was $29)

Supabase and Firebase hand the browser a key on purpose. What protects your rows is a policy — a separate thing somebody has to write, and the app works perfectly without it.

by saltyhash · Code Recycle admin

Get it free — beta

Every claim on this page is refundable if it is untrue — refund policy.

Verified: 17 tests · 10/10 mutations caught

The anon key is meant to be public. An assistant asked for "a table for user notes" writes the table; the app works immediately because that key can read it. It keeps working, for everyone, including whoever opens devtools, copies the key off your own page and queries the table directly. Nothing errors. The app is not broken — it is just also not private.

Why the app working proves nothing

The anon key is meant to be public. An assistant asked for "a table for user notes" writes the table; the app works immediately because that key can read it. It keeps working, for everyone, including whoever opens devtools, copies the key off your own page and queries the table directly. Nothing errors. The app is not broken — it is just also not private.

The mirror-image failure

Turn row-level security ON and write no policies and Postgres denies everything. The table is perfectly safe and completely unusable: every query returns zero rows, silently, with no error. People debug that for hours, and the fix that "works" is the one that turns RLS back off.

So both are reported, DIFFERENTLY. A table nobody can read is not a security finding — it is a broken feature, and calling it a vulnerability points at exactly the wrong remedy.

| verdict | meaning | |---|---| | `world_writable` | anyone with the public key can write — the worst available | | `rls_disabled` | table created, RLS never enabled | | `world_readable` | a policy reads using (true) | | `locked_out` | RLS on, no policies: safe and broken, not a leak | | `protected` | RLS on with a conditional policy |

The details that decide whether it is right

Migrations are folded together before judging — a table is created in one file and secured in the next by convention, and judging file-by-file would report a false finding on essentially every correctly-secured project.

A later DISABLE beats an earlier ENABLE. Not a corner case: it is the exact sequence that produces the bug.

Every policy is kept, not just the last. Postgres ORs permissive policies together, so an open using (true) added early and never dropped leaves the table wide open even though the proper owner-scoped policy added later is perfect. Reporting the most recent policy would look at that table and see the good one.

An omitted FOR clause means ALL, so reading it as select-only would downgrade the most permissive shape somebody can write.

What it cannot see

Policies created by hand in a dashboard. It reads files — no connection, no credentials, no execution — so when it finds nothing it SAYS so rather than printing a clean bill of health it has no basis for. And it confirms a filter exists, not that the filter is correct.

Verified

17 tests, 10 deliberate defects, all 10 caught — including a re-disabled table reading as protected, using (true) no longer recognised as unconditional, the locked-out table reported as a leak, and an empty scan printing "no problems found".

Delivery

Source delivered as a private repository invite within 24 hours of purchase. Single-product commercial license: use and modify in any number of products; no redistribution or resale of the source.

Interface

What you call, and what comes back. Types and signatures only — the implementation ships with the source.

  export function scanDatabaseExposure(files: SourceFile[], options: ScanOptions = {}): TableFinding[];
  export function hasOpenData(findings: TableFinding[]): boolean;
  export function formatTableFindings(findings: TableFinding[]): string;

01Capabilities

Does

  • + PostgreSQL database
  • + Row level security enforcement
  • + Pre-deploy checks

Doesn’t

  • No exclusions declared

02Requirements & stack

Depends on

No declared dependencies

Credentials needed

None declared

Stack

typescript

03Community

No endorsements yet

No verified confirmations yet — be the first.

Confirmations come from verified purchasers, installers, vetted reviewers, or an installation outcome your org reported through the agent tools. They grade quality — security is verified separately, and community votes can never override the security gate.

Open an issue

Sign in to confirm — weight comes from verified usage, not vote count.

0 open · 0 answered · 0 fixed · 1 said it worked

04Trust Passport

Full passport →
–/100

0/0 automated components pass. An automated score is never a security guarantee.

✓ Verified · first-partyreviewed Sep 20, 2026 · re-verification due Dec 19, 2026
  • publisher identity Publisher status verified; 1 verification(s) on file
  • malicious pattern scan No known malicious-behavior patterns across 8 source file(s) plus listing text
  • capability contract All 0 observed capability reference(s) match the declared manifest
  • agent safety scan No injection patterns in agent-readable content
  • provenance No release signature or provenance attestation
  • behavioral sandbox Not performed in this environment — requires the production isolated runner (docs/sandbox-requirements.md). No untrusted code is ever executed on the application host.

Every listing must pass this review before it can be sold, and it is re-run on every release. Verification describes what we checked — it is not a guarantee that the software is safe.

VersionChannelReleasedNotes
1.0.0stableAug 11, 2026First public release.