Supabase RLS eskanerra: errenkada-mailako segurtasun falta edo apurtuta duten taulak aurkitu

RLS eskaneatze externo batek zer frogatu dezakeen

RLS eskaneatze pasibo bat Supabasek https://[project].supabase.co/rest/v1/ helbidean agertzen duen PostgREST amaiera-puntuaren aurka exekutatzen da. anon gako publikoa baino ez du erabiltzen — nabigatzaileak erabiltzen duen gako bera — eta taula-zerrendaren metadatuak, irakurketa anonimoak eta idazketa anonimoak frogatzen ditu. Ez du inoiz erabiltzaile gisa autentikatzen eta ez du inoiz service-role pribilegiorik ukitzen. Egin dezakeen edozer egin dezake Interneteko autentikatu gabeko erasotzaile batek.

Datu-basetik kanpo, eskaner batek hurrengoa konfiantza handiz baieztatu dezake:

• RLS desgaituta dago taula batean. PostgREST-ek errenkadak itzultzen ditu SELECT anonimo baterako RLS itzalita dagoenean edo politika batek hori baimentzen duenean. Bi kasuetan aurkikuntza bat da.
• Rol anonimoak taulak zerrendatu ditzake. Anon gakoarekin egindako GET /rest/v1/ batek anon rolak edozein pribilegio duen taula bakoitzaren OpenAPI eskema itzultzen du. IAk sortutako aplikazioek maiz USAGE ematen diote eskemari eta SELECT taula bakoitzari, eta horrek eskema-mapa osoa erakusten du nahiz eta RLSk benetako irakurketak ukatu.
• Rol anonimoak txertatu dezake. Zutabeen formaren asmakizun bat duen POST baten froga arrakastatsua izango da RLSk ez badu INSERT ukatzen duen politikarik — nahiz eta SELECT blokeatuta egon.
• Service-role gakoa nabigatzailearen bundle-ean dago. RLSrekin lotuta: eskaner batek JavaScript bundle-ean SUPABASE_SERVICE_ROLE_KEY edo role: service_role duen edozein JWT aurkitzen badu, RLS ezdeusten da — gako horren jabea edozein politika saihesten du.

Kanpoko eskaneatze batek zer ezin duen frogatu

Izan zaitez zintzo eskanerraren mugekin. Kanpoko RLS eskaneatze batek ezin du irakurri zure pg_policies taula, ez zure migrazio-fitxategiak, ez politika baten predikatu zehatza. Kutxa beltzaren portaeratik atera ahala ondorioztatzen du, eta horrek esan nahi du batzuetan aurkikuntza bat berariazko datu publiko gisa amaitzen dela (marketin-buletin baten taula, produktuen katalogo publiko bat). FixVibe txostenak konfiantza ertaineko gisa markatzen ditu eskanerrak asmoa argitu ezin duenean — berrikusi taularen izena eta erabaki.

IA tresnek sortzen dituzten RLS apurtuaren lau formak

Cursor, Claude Code, Lovable edo Bolt Supabasera bideratzen dituzunean, milaka aplikazioetan RLS apurtuaren lau eredu berdinak agertzen dira. Bakoitzak motaren egiaztapena gainditzen du, konpilatzen da eta bidaltzen da:

1. forma: RLS ez da inoiz gaitu

Hutsegite-modurik ohikoena. Migrazioak taula sortzen du baina garatzaileak (edo IA tresnak) ALTER TABLE ... ENABLE ROW LEVEL SECURITY ahaztu egiten du. PostgREST-ek pozik zerbitzatzen dio taula osoa anon gakoa duen edonori. Konponbidea: ALTER TABLE public.[name] ENABLE ROW LEVEL SECURITY; ALTER TABLE public.[name] FORCE ROW LEVEL SECURITY;. FORCE ez da aukerakoa — gabe taularen jabeak (eta taularen jabetza duen edozein rolek) RLS saihesten du.

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

2. forma: RLS gaituta, politikarik ez

Hutsegite sotilagoa. RLS gaituta dago baina ez da politikarik idatzi. PostgreSQLko lehenetsia ukatzea da, beraz, autentikatutako erabiltzaileek ez dute ezer ikusten — eta garatzaileak USING (true) gehitzen du aplikazioa funtziona dadin, eta horrek guztiei dena irakurtzeko baimena ematen die. Konponbidea: idatzi auth.uid()-rekin mugatzen den politika bat: CREATE POLICY "select_own" ON public.[name] FOR SELECT USING (auth.uid() = user_id); eta bat datorren INSERT/UPDATE/DELETE politika.

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

3. forma: Politikak zutabea bere buruarekin alderatzen du

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.

4. forma: Politika SELECT-en baina ez INSERT/UPDATE-n

Garatzaileak irakurketak blokeatzen ditu baina idazketak ahazten ditu. RLS politikak komando-bakoitzekoak dira. FOR SELECT-ek irakurketak baino ez ditu babesten; bezero anonimo batek oraindik INSERT egin dezake politikarik ukatzen ez badu. Konponbidea: idatzi politika bat komando bakoitzeko, edo erabili FOR ALL USING eta WITH CHECK klausula esplizituekin.

Nola funtzionatzen duen FixVibe Supabase RLS eskanerrak

baas.supabase-rls egiaztapena hiru etapatan exekutatzen da, bakoitza konfiantza-maila esplizituekin:

1. 1. etapa — hatz-marka. Eskanerrak zabaldutako aplikazioa arakatzen du, JavaScript bundle-a aztertzen du eta Supabase proiektuaren URLa eta anon gakoa exekuzio-konfiguraziotik ateratzen ditu. DNS asmakizunik gabe, indar gordinik gabe — nabigatzaileak irakurtzen duena irakurtzen du.
2. 2. etapa — eskema aurkikuntza. Anon gakoarekin GET /rest/v1/ bakar batek anon rolak ikus dezakeen taula bakoitzeko OpenAPI eskema itzultzen du. Eskanerrak taulen izenak gordetzen ditu baina ez ditu errenkada-datuak irakurtzen etapa honetan.
3. 3. etapa — irakurketa eta idazketa frogak. Aurkitutako taula bakoitzarentzat, eskanerrak SELECT anonimo bat egiten du limit=1 mugarekin. Errenkadak itzultzen badira, RLS permisiboa da. Eskanerra hor gelditzen da — ez ditu errenkadak zenbatzen, ez du orrikatzen, ez ditu datuak aldatzen. INSERT frogak egiaztatutako domeinu-jabetzaren eta esplizituki onartutako aukeraketaren atzean daude; ez dira inoiz egiaztatu gabeko helburuen aurka exekutatzen.

Aurkikuntza bakoitza eskaeraren URL zehatzarekin, erantzunaren egoerarekin, erantzunaren formarekin (goiburua bakarrik) eta taularen izenarekin bidaltzen da. Aurkikuntzaren behealdean dagoen IA konponketa-gonbita Supabase SQL editorean exekutatzen duzun kopiatzeko-itsasteko SQL bloke bat da.

Eskanerrak zerbait aurkitzen duenean zer egin

RLS aurkikuntza bakoitza exekuzio-larrialdi bat da. PostgREST amaiera-puntu publikoak minutuetan eskaneatzen dituzte erasotzaileek. Konponketa-sekuentzia mekanikoa da:

1. Auditatu taula bakoitza. Exekutatu SELECT schemaname, tablename, rowsecurity FROM pg_tables WHERE schemaname = 'public'; Supabase SQL editorean. rowsecurity = false duen edozein errenkada arazo bat da.
2. Gaitu RLS taula publiko bakoitzean. Lehenetsi ENABLE ROW LEVEL SECURITY eta FORCE ROW LEVEL SECURITY sortutako taula bakoitzean — bihurtu ezazu migrazio-txantiloi bat.
3. Idatzi politikak komando-bakoitzeko. Ez erabili FOR ALL USING (true). Idatzi politika esplizituak SELECT, INSERT, UPDATE, DELETE-rentzat — bakoitza auth.uid()-rekin edo auth.jwt()-tik datorren org-id zutabe batekin mugatuta.
4. Egiaztatu bigarren kontu batekin. Eman izena beste erabiltzaile gisa, saiatu beste erabiltzaile baten erregistroak REST APIaren bidez zuzenean irakurtzen. Erantzuna 200 bada, politika apurtuta dago.
5. Berriz eskaneatu. Konponketa aplikatu ondoren, exekutatu berriz FixVibe eskaneatze bat URL beraren aurka. baas.supabase-rls aurkikuntzak garbitu beharko luke.

-- 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;

Hau beste eskaner batzuekin nola alderatzen den

DAST tresna generiko gehienek (Burp Suite, OWASP ZAP, Nessus) ez dakite zer den PostgREST. Zure aplikazioa arakatuko dute, /rest/v1/ bidea alde batera utziko dute eta ulertzen dituzten HTML orrien berri emango dute. Snyk eta Semgrep analisi estatikoaren tresnak dira — RLS deiak falta dituzten migrazio-fitxategiak aurkitzen dituzte zure biltegian, baina ezin dute frogatu zabaldutako datu-basea gaizki konfiguratuta dagoenik. FixVibek hutsunea betetzen du: pasiboa, BaaS-aware, autentikatu gabeko erasotzaile batek URL publikotik froga dezakeenean zentratua.

Maiz egiten diren galderak

Hurrengo urratsak

Egin FixVibe eskaneatze doako bat zure ekoizpen-URLaren aurka — baas.supabase-rls egiaztapena plan guztietan gaituta dago, doako maila barne. Supabase proiektutik beste zer iragazi daitekeen sakonago irakurtzeko, ikus Supabase service role gakoa JavaScript-en agerian eta Supabase biltegiratze-ontziaren segurtasun-zerrenda. BaaS hornitzaile guztietako ikuspegi orokorra ikusteko, irakurri BaaS konfigurazio okerren eskanerra.