service_role
Bypasses RLS. Completely.
One leaked service_role key reads and writes every row of every table, whatever your policies say. It ends up in client bundles more often than anyone wants to admit.
Exposure scanner for Supabase & vibe-coded apps
One leaked key reads every row of every table.
Sentris reads your repo the way you wrote it — migrations, config, route handlers — plus your live bundle. Four checks. Every finding comes with the exact line and the SQL to fix it.
Connect GitHub — run all four checks
Read-only, nothing is cloned, revoke it whenever you like. Your RLS policies, storage buckets and route handlers live in the repo — that is the only place they can be checked.
No login needed — but a URL scan only sees your client bundle, so it covers exposed secrets and nothing else.
By scanning you confirm the app is yours or that you are authorised to test it. See the terms.
Scanning is free · findings & fixes from $19/month · cancel any time
- No login to scan
- Results in seconds
- Read-only — nothing is cloned
- Proven — we never exploit
sentris — sample outputSample
$ sentris scan acme/storefront
▸ tree 1 listing · 34 files read
▸ c1 migrations · declarative schema
▸ c2 repo files · .env · live bundle
▸ c3/c4 route handlers · buckets
■ CRITICAL · confirmed
service_role key in client bundle
/_next/static/chunks/main-8c41f2.js:1
eyJ••••Rlc3Rz [masked]
■ CRITICAL · potential
table public.leads has no RLS
supabase/migrations/0002_leads.sql:3
Illustrative output · your report names your filesSee a real report →
Sentris hunts ▸
Three mistakes turn a side project into a breach.
None of these are exotic. All three are one line of config, and each one hands a stranger your whole table. If that table holds personal data, the GDPR ceiling for the resulting breach is €20 million or 4% of worldwide annual turnover, whichever is higher (Art. 83(5)) — before you count the API bill nobody authorised.
RLS off
The anon key is public by design.
It ships in your browser bundle — that is correct. But a table without RLS is readable by anyone holding it, and that is everyone who opened your app.
public bucket
Every object, one URL away.
A public bucket serves files to anyone with the link — no key, no login, no expiry. Right for avatars. Not right for invoices.
Not a warning. A fix.
Every finding names the file and the line, shows masked proof, and hands you SQL you can paste. Anything static analysis cannot prove is labelled potential — we would rather report one finding fewer than one that is wrong.
Fix it, hit re-scan, and the report tells you what you cleared. That loop is the product: not the list, the “resolved”.
- EvidenceExact file and line, masked — never a raw key
- FixCopy-paste SQL or code, not 'consider reviewing'
- Honestyconfirmed vs potential, stated per finding
sentris — sample outputSample
$ sentris scan acme/storefront
▸ tree 1 listing · 34 files read
▸ c1 migrations · declarative schema
▸ c2 repo files · .env · live bundle
▸ c3/c4 route handlers · buckets
■ CRITICAL · confirmed
service_role key in client bundle
/_next/static/chunks/main-8c41f2.js:1
eyJ••••Rlc3Rz [masked]
■ CRITICAL · potential
table public.leads has no RLS
supabase/migrations/0002_leads.sql:3
fix
alter table public.leads enable row level security; create policy "Owners read their own rows" on public.leads for select to authenticated using (auth.uid() = user_id);
Four checks. Published rules. No mystery box.
Most scanners will not tell you what they look for. Here is the entire detection surface, what each check reads, and how sure it is allowed to be.
| ID | Check | Detects | Source | Confidence |
|---|---|---|---|---|
| C1 | Row Level Security | Tables in public shipping without RLS, and policies that grant using (true) | Repo — migrations & schema | potential / confirmed |
| C2 | Exposed secrets | service_role, Stripe and AI-provider keys, committed .env files | Repo files + live bundle | confirmed |
| C3 | Broken access control | Routes taking a caller-supplied id with no auth check | Repo — route handlers | potential |
| C4 | Public storage | Buckets marked public in config, a migration, or createBucket() | Repo — config, SQL, source | confirmed |
Never flagged
Anon and publishable keys belong in your client. Rules classify by what a key can do, not by whether it looks like a secret — so the keys that are meant to be public stay quiet.
Out of scope
Server infrastructure & DDoS · Dependency CVEs · TLS / cryptography depth · Social engineering · Business logic beyond access control · Mobile apps · Load / performance. Stated on every report, not buried.
A URL scanner cannot see your schema.
URL-only scanners
$5–59 / mo
Black-box. They see what the browser sees and nothing else — so RLS, policies, buckets and unguarded routes are structurally invisible to them. Then they bury you in generic warnings.
Sentris
from $19/month
Reads the repo the way you wrote it — migrations, config, route handlers — then proves what it found against your running app. Four checks, published rules, a measured false-positive rate, evidence and a fix per finding.
Enterprise / compliance
$350–10,000 / mo
Real depth, real pentests, real attestations — with a seat minimum and a sales call attached. The right tool once you are selling to enterprises. Not for shipping this weekend.
| Sentris | URL-only | Enterprise | Supabase advisor | |
|---|---|---|---|---|
| Reads your repo | ■ yes | — no | ■ yes | — no |
| Sees migrations before they ship | ■ yes | — no | ◧ partly | — no |
| Checks RLS & policies | ■ yes | — no | ■ yes | ■ yes |
| Checks the live client bundle | ■ yes | ■ yes | ■ yes | — no |
| Ships a copy-paste fix | ■ yes | ◧ partly | ◧ partly | ■ yes |
| Re-scans on a schedule | ■ yes | ■ yes | ■ yes | — no |
| No sales call, no seat minimum | ■ yes | ■ yes | — no | ■ yes |
Supabase's own advisor is in that table on purpose — it is free, it is good, and it is the alternative most of you already have. It reads your running database. It does not read the migration before you ship it, your client bundle, or your route handlers.
Compared in full:SnykSemgrepGitHub Advanced Securitythe Supabase Security AdvisorVibe App ScannerCheckVibeSecurityScanner.devLovable's built-in security scanner
Handing a repo to a security tool should give you pause.
So here is exactly what happens to it. A product that sells security has to survive its own audit first.
Read-only by default
Scanning reads contents and metadata and writes nothing. A pull request is opened only for targets you explicitly switched it on for — never on your default branch, and never merged for you. Revoke the App in your GitHub settings whenever you like.
Never cloned
Files are read during the scan and gone after it. No copy of your repo exists here.
Masked at the source
A found key is masked before it touches our database, the UI, or a log line.
Proven, not exploited
One masked example as evidence. Never a full table, never a write, never a flood.
Throttled
Rate-limited per address and per target host, so a scan stays inside every platform's AUP.
Gated by ownership
Unverified targets get passive checks only. Active checks need proof the asset is yours.
I'm Luca. Sentris is a one-person project, and I would rather you knew that up front.
I build on the same stack you do — Supabase and Next.js, mostly in evenings and weekends. There is no security team behind this, and a security tool that implies one it does not have has already told you its first lie.
What I can put my name to instead: all four checks are published in full on this page, every rule runs against a fixed corpus of clean and vulnerable repos before it ships, and the clean corpus has to come back with zero findings or the rule does not go out. Where the code cannot prove something, the report says potential and not something more flattering.
And the rate that comes out of that corpus is on the site, not in a drawer: precision 1.000 and recall 1.000, with the caveats about how small the corpus is printed above the table rather than under it. If a new rule pushes it down, the number goes down.
@urti_lucaFound a false positive? Tell me and I will fix the rule.
Scanning is free. The fix is what you pay for.
No login to scan, and you see how many exposures you have before you pay anything. Where they are and how to close them is the product. The tiers differ in how much you watch and how often, not in how deep we look: every plan runs all four checks.
Starter
$19/month
One app, watched.
- One connected target — a repo or a live URL
- All four checks, with evidence and the copy-paste fix
- Unlimited re-scans to confirm your fixes landed
- Weekly monitoring, alert only when something is new
Most popular
Pro
$49/month
Everything you ship.
- Up to five connected targets
- All four checks, with evidence and the copy-paste fix
- Unlimited re-scans to confirm your fixes landed
- Nightly monitoring, alert only when something is new
- Scan history and resolved-since-last-scan tracking
Team
$99/month
The whole estate.
- Unlimited connected targets
- All four checks, with evidence and the copy-paste fix
- Unlimited re-scans to confirm your fixes landed
- Nightly monitoring, alert only when something is new
- Every repo the GitHub App can see, across organisations
Cancel any time · billed through Stripe · you pick the plan after the scan · 14-day refund
What the subscription is actually for
A one-off scan tells you about today. Your app ships tomorrow — a migration lands without RLS, a key gets pasted into a client component, a bucket is flipped public to debug an upload.
Sentris re-scans on a schedule and diffs against the last run. You hear from it only when something is new — the same finding never mails you twice, because a monitor you learn to ignore protects nobody.
When a scan comes back clean, that is the product working. You are buying the quiet.
Which one
- StarterOne app you actually care about. Checked weekly.
- ProYou ship across a handful of repos and want to hear about it the next morning.
- TeamMore projects than you can name from memory, across organisations.
Moving between plans is a click in Stripe, and the change takes effect here by itself.
The questions worth asking.
Is this a penetration test?
No, and it never claims to be. Sentris reports reproducible findings with evidence, at a point in time. It is not a pentest, not a certification, and carries no warranty. If you need an attestation to close an enterprise deal, you need a pentest firm — not us.
Do you store my code?
No. The repo is never cloned. Files are read during the scan and discarded when it ends. What we keep is the findings — and any secret inside them is masked before it is written anywhere.
Can Sentris write to my repo?
Only if you switch it on, per repository, and it is off for every repository until you do. When it is on, Sentris opens a pull request that adds exactly one new file: a migration closing findings it confirmed against your running system. It never pushes to your default branch, never replaces an existing line, never merges anything, and never opens a pull request for something it could not prove. Secrets are excluded on purpose — a pull request that deletes a leaked key creates false safety, because the key is still compromised and only you can rotate it. Leave the switch off and Sentris behaves exactly as it did before this existed.
What if you find nothing?
You get a clean result that lists exactly what was checked and what is explicitly out of scope, so you know what the result covers. Then it keeps re-scanning on your plan's schedule — weekly on Starter, nightly on Pro and Team — and alerts you the first time something new appears. The value is the ongoing 'still clean', not only the first report.
How do you keep false positives down?
Two ways. Rules classify by capability, so anon and publishable keys — which belong in your client — are never flagged. And anything code alone cannot prove is labelled potential rather than sold to you as a breach. Every rule runs against a fixed corpus of clean and vulnerable repos, and the clean one must return zero findings before a rule ships. That corpus is also the measurement: precision 1.000 and recall 1.000 across 24 planted findings in 9 repositories, published in full at /precision with the date, the commit and the command to reproduce it. Nobody else in this category publishes theirs.
Supabase already warns me about missing RLS. Why do I need this?
Because the advisor reads your running database, and that is only one of the places these mistakes live. It cannot see the migration sitting in your branch before it ships, it cannot see the service_role key your client bundle is serving to every visitor, and it cannot see a route handler that takes an id and never checks who is asking. It also does not watch: it answers when you open it. Sentris covers all four surfaces and re-checks them on a schedule. If missing RLS is genuinely your only concern, use the advisor — it is free and it is good.
What do I get for $19?
Every exposure the four checks find, each with the exact file and line, masked evidence, and a copy-paste fix — plus re-scans on a schedule that alert you the first time something new appears. Scanning itself is free and needs no login: you see how many exposures you have before you pay anything. What you are paying for is where they are and how to close them. No trial maze, no upsell ladder.
Can I see a real report before I pay?
Yes — the whole thing, at /sample. It is an unedited scan of a deliberately vulnerable Supabase app we maintain, rendered by the same code that renders a customer's report: every finding, every file and line, the masked evidence and the SQL fix. We publish that repo rather than a customer's, and nothing on the page is trimmed for the screenshot.
Who is behind this?
One person, building on the same stack you do — Supabase, Next.js, shipped in evenings and weekends. Sentris is not a company with a security team behind it, and pretending otherwise would be the first thing worth distrusting about a security tool. What it is: four checks that are published in full, run against a fixed corpus of clean and vulnerable repos before they ship, and honest about the difference between what they proved and what they suspect.
Can I cancel?
Any time, from Stripe. Access follows your subscription status automatically — there is nothing to email us about.
Our precision and recall, in public9 repos, 24 planted findings, measured 2026-08-11
Free security rules for your AI coding toolthe mistake not made needs no fix
Find it before someone else does.
The scan takes seconds and costs nothing. If it comes back clean you have lost a minute. If it does not, you found the thing before it found you.
Connect GitHub — run all four checks
Read-only, nothing is cloned, revoke it whenever you like. Your RLS policies, storage buckets and route handlers live in the repo — that is the only place they can be checked.
No login needed — but a URL scan only sees your client bundle, so it covers exposed secrets and nothing else.
By scanning you confirm the app is yours or that you are authorised to test it. See the terms.
No login to scan · findings & fixes from $19/month · cancel any time