Supabase RLS-skannari: finn talvur við vantandi ella brotnari row-level security

Hvat ein uttarlig RLS-skanning kann prógva

Ein passiv RLS-skanning verður koyrd móti PostgREST-endapunktinum, sum Supabase avdúkar á https://[project].supabase.co/rest/v1/. Hon brúkar bert hin almenna anon-lykilin — sama lykil sum tín kagari brúkar — og royndar talvulistar-metadáta, óvátt lestur og óvátt skriving. Hon vátta seg aldri sum brúkara og nertir aldri service-role-rættindi. Alt, sum hon kann gera, kann ein óvátt árásarmaður á alnetinum eisini gera.

Uttanífrá dátugrunninum kann ein skannari vátta hetta við høgari álit:

• RLS er deaktiverað á einari talvu. PostgREST endurgevur røðir fyri eitt óvátt SELECT, tá RLS er sløkt ella tá ein politikkur loyvir tað. Báðir førleikar eru ein finding.
• Hin anonyma rólvan kann lista talvur. Eitt GET /rest/v1/ við anon-lyklinum endurgevur OpenAPI-skemað fyri hvørja talvu, sum anon-rólvan hevur eitt eitt og hvørt rættindi til. AI-framleiddar appir vísa ofta USAGE á skemað og SELECT á hvørja talvu, sum avdúkar alt skemakortið, sjálvt um RLS noktar tær veruligu lesturnar.
• Hin anonyma rólvan kann seta inn. Eitt royndandi POST við einum gáti á dálkaformini lukkast, um RLS ikki hevur ein INSERT-politikk, sum noktar tað — sjálvt um SELECT er læst.
• Service-role-lykilin er í kagara-bunkanum. Næst RLS: um ein skannari finnur SUPABASE_SERVICE_ROLE_KEY ella nakra JWT við role: service_role í JavaScript-bunkanum, er RLS einki vert — tann, ið hevur lykilin, fer uttanum hvønn politikk.

Hvat ein uttarlig skanning ikki kann prógva

Ver ærlig um markini hjá skannaranum. Ein uttarlig RLS-skanning kann ikki lesa tína pg_policies-talvu, tínar migratiónsskjøl ella tað neyva prædikatið hjá nøkrum politikki. Hon álítur av sortakassaatferð, sum merkir, at hon ístundum fráboðar eitt finding, sum vísir seg at vera ætlaðar almennar dátur (ein marknaðarfrøðisligur fréttabrævatalva, eitt almennt vørukatalogur). FixVibe-fráboðanin merkir hesi sum miðal álit, tá skannarin ikki kann skilja ætlanina — kanna talvunavnið og avger.

Tær fýra brotnu RLS-formirnar, sum AI-amboð framleiða

Tá tú peikar Cursor, Claude Code, Lovable ella Bolt á Supabase, koma somu fýra brotnu RLS-mynstur fram í túsundtals appum. Hvør ein bestendur typu-eftirkanning, kompilerar og verður avgreidd:

Form 1: RLS aldri virkjað

Hin vanligasta feilformin. Migratiónin stovnar talvuna, men menningarmaðurin (ella AI-amboðið) gloymir ALTER TABLE ... ENABLE ROW LEVEL SECURITY. PostgREST veitir glaðiliga heila talvuna til allar við anon-lyklinum. Fix: ALTER TABLE public.[name] ENABLE ROW LEVEL SECURITY; ALTER TABLE public.[name] FORCE ROW LEVEL SECURITY;. FORCE er ikki valfrítt — uttan tað fer talvuogandin (og hvør rólva við talvuogandi) uttanum RLS.

ALTER TABLE public.[name] ENABLE ROW LEVEL SECURITY;
ALTER TABLE public.[name] FORCE  ROW LEVEL SECURITY;

Form 2: RLS virkjað, ongir politikkar

Ein meiri rakin feilur. RLS er virkjað, men ongir politikkar eru skrivaðir. Standardin í PostgreSQL er nokta, so vátt brúkarar síggja einki — og menningarmaðurin leggur USING (true) afturat fyri at fáa appina at virka, sum loyvir øllum at lesa alt. Fix: skriva ein politikk, sum verður avmarkað við auth.uid(): CREATE POLICY "select_own" ON public.[name] FOR SELECT USING (auth.uid() = user_id); og ein passandi INSERT/UPDATE/DELETE-politikk.

CREATE POLICY "select_own"
  ON public.[name]
  FOR SELECT
  USING (auth.uid() = user_id);

Form 3: Politikkur samanberir dálk við seg sjálvan

A copy-paste artefact. The developer writes <code>USING (user_id = user_id)</code> — which is always true — instead of <code>USING (auth.uid() = user_id)</code>. Type-checks pass; the policy permits every row. <strong>Fix:</strong> always compare a column to a function call (<code>auth.uid()</code>, <code>auth.jwt()->>'org_id'</code>, etc.), never to itself or to a constant.

Form 4: Politikkur á SELECT, men ikki á INSERT/UPDATE

Menningarmaðurin læsir lestur men gloymir skriving. RLS-politikkar eru per kommando. FOR SELECT verjir bert lestur; ein anonymur klientur kann framvegis INSERT, um eingin politikkur noktar tað. Fix: skriva ein politikk per kommando, ella brúk FOR ALL við greiðum USING- og WITH CHECK-klausulum.

Hvussu FixVibes Supabase RLS-skannari virkar

baas.supabase-rls-eftirkanningin koyrir í trimum stigum, hvørt við greiðum álitsstigi:

1. Stig 1 — fingraavrygging. Skannarin crawlar tína deployaðu app, parsar hennara JavaScript-bunka og dregur Supabase-projektsins URL og anon-lykil úr runtime-skipanini. Eingin DNS-gáti, eingin brute force — hon lesur tað, kagarin lesur.
2. Stig 2 — skema-uppgøtan. Eitt einstakt GET /rest/v1/ við anon-lyklinum endurgevur OpenAPI-skemað fyri hvørja talvu, sum anon-rólvan kann síggja. Skannarin skrásetir talvunøvn, men lesir onga røðdátu á hesum stigi.
3. Stig 3 — lestrar- og skrivirannsóknir. Fyri hvørja uppgøtaða talvu sendir skannarin eitt einstakt anonymt SELECT við limit=1. Um røðir koma aftur, er RLS loyvandi. Skannarin steðgar har — hon telur ikki upp røðir, paginerar ikki, broytir ongar dátur. INSERT-rannsóknir eru avmarkaðar bak váttað domena-ogandi og greitt opt-in; tær koyra aldri móti óváttaðum málum.

Hvør finding kemur við neyvu request-URL, response-status, response-formi (bert headara) og talvunavninum. AI-fix-leiðbeiningin nedst í findingini er ein copy-paste-SQL-blokkur, sum tú koyrir í Supabase SQL-redigeringini.

Hvat tú gert, tá skannarin finnur nakað

Hvør RLS-finding er ein runtime-neyðstøða. Almenn PostgREST-endapunkt verða skannað av árásarmonnum innan minuttir. Bótingarrøðin er mekanisk:

1. Endurskoða hvørja talvu. Koyr SELECT schemaname, tablename, rowsecurity FROM pg_tables WHERE schemaname = 'public'; í Supabase SQL-redigeringini. Hvør røð við rowsecurity = false er ein trupulleiki.
2. Virkja RLS á hvørjari almennari talvu. Brúk sum standard ENABLE ROW LEVEL SECURITY og FORCE ROW LEVEL SECURITY á hvørjari talvu, sum verður stovnað — ger tað til eina migratiónssniðsmynd.
3. Skriva politikkar kommando fyri kommando. Brúk ikki FOR ALL USING (true). Skriva greiðar politikkar fyri SELECT, INSERT, UPDATE, DELETE — hvør avmarkaður til auth.uid() ella ein org-id-dálk frá auth.jwt().
4. Vátta við aðrari kontu. Tilmelda teg sum annar brúkari, royn at lesa eins annars brúkaras skrásetingar beinleiðis um REST-API'in. Um svarið er 200, er politikkurin brotin.
5. Skanna aftur. Eftir at fixa er løgd á, koyr eina nýggja FixVibe-skanning móti somu URL. baas.supabase-rls-findingin eigur at hvørva.

-- Audit every table for missing RLS. Run in the Supabase SQL editor.
SELECT schemaname, tablename, rowsecurity
FROM   pg_tables
WHERE  schemaname = 'public'
ORDER  BY rowsecurity, tablename;

Hvussu hetta verður samanborið við aðrar skannarar

Tey flestu generisku DAST-amboð (Burp Suite, OWASP ZAP, Nessus) vita ikki, hvat PostgREST er. Tey crawla tína app, ignorera /rest/v1/-leiðina og fráboða um HTML-síðurnar, tær skilja. Snyk og Semgrep eru statisk analyseamboð — tey finna migratiónsskjøl í tínum repo við vantandi RLS-kalli, men tey kunnu ikki prógva, at hin deployaði dátugrunnur er misskipaður. FixVibe situr í holinum: passiv, BaaS-vitandi, einbeint um, hvat ein óvátt árásarmaður kann prógva uttanífrá hini almennu URL.

Ofta settir spurningar

Næstu stig

Koyr eina ókeypis FixVibe-skanning móti tíni framleiðslu-URL — baas.supabase-rls-eftirkanningin er virkin á hvørjari ætlanini, eisini hinari ókeypis. Fyri djúpari lestur um, hvat annað kann leka úr einum Supabase-projekti, sí Supabase service role key avdúkaður í JavaScript og Supabase goymslubøtta-trygdarlista. Fyri tað omfattandi yvirlit yvir allar BaaS-veitarar, les BaaS-misskipansskannari.