// docs / baas security / supabase rls scanner

Сканер Supabase RLS: знайдзіце табліцы з адсутнай або зламанай бяспекай на ўзроўні радкоў

Name: Сканер Supabase RLS: знайдзіце табліцы з адсутнай або зламанай бяспекай на ўзроўні радкоў
Brand: FixVibe
Author: FixVibe

Бяспека на ўзроўні радкоў (RLS) — гэта адзінае, што стаіць паміж дадзенымі вашых кліентаў і інтэрнэтам, калі вы выпускаеце праграму на аснове Supabase. ШІ-інструменты кадавання генеруюць код у форме RLS, які кампілюецца, выпускаецца і ціха зліваюць дадзеныя — табліцы, створаныя без уключэння RLS, палітыкі, якія чытаюць, але ніколі не абмяжоўваюць, прэдыкаты, якія параўноўваюць слупок з самім сабой. Гэты артыкул паказвае, што сканер Supabase RLS можа даказаць звонку, чатыры формы зламанага RLS, якія з'яўляюцца ў vibe-кадаваных праграмах, і як прасканаваць ваша ўласнае разгортванне менш чым за хвіліну.

Што можа даказаць знешняе сканаванне RLS

Пасіўнае сканаванне RLS выконваецца супраць канчатковай кропкі PostgREST, якую Supabase прадастаўляе па адрасе https://[project].supabase.co/rest/v1/. Яно выкарыстоўвае толькі публікаваны ключ anon — той самы ключ, які выкарыстоўвае ваш браўзер — і зандуе метаданыя спісу табліц, ананімныя чытанні і ананімныя запісы. Яно ніколі не аўтэнтыфікуецца як карыстальнік і ніколі не выкарыстоўвае прывілеі сэрвіснай ролі. Усё, што яно можа рабіць, можа рабіць неаўтарызаваны зламыснік у інтэрнэце.

Звонку базы дадзеных сканер можа пацвердзіць наступнае з высокай упэўненасцю:

RLS адключаны на табліцы. PostgREST вяртае радкі для ананімнага SELECT, калі RLS адключаны або калі палітыка гэта дазваляе. Любы выпадак — гэта знаходка.
Ананімная роля можа пералічваць табліцы. GET /rest/v1/ з ключом anon вяртае схему OpenAPI для кожнай табліцы, да якой у ролі anon ёсць любыя прывілеі. ШІ-згенераваныя праграмы часта прадастаўляюць USAGE для схемы і SELECT для кожнай табліцы, што агаляе поўную карту схемы, нават калі RLS адхіляе фактычныя чытанні.
Ананімная роля можа ўстаўляць. Зандуючы POST з меркаваннем пра форму слупкоў будзе паспяховым, калі ў RLS няма палітыкі INSERT, якая адхіляе яго — нават калі SELECT заблакаваны.
Ключ сэрвіснай ролі знаходзіцца ў браўзерным бандле. Сумежна з RLS: калі сканер знаходзіць SUPABASE_SERVICE_ROLE_KEY або любы JWT з role: service_role у JavaScript-бандле, RLS становіцца бескарысным — уладальнік гэтага ключа абыходзіць кожную палітыку.

Што знешняе сканаванне не можа даказаць

Будзьце сумленнымі адносна межаў сканера. Знешняе сканаванне RLS не можа прачытаць вашу табліцу pg_policies, вашы файлы міграцый або дакладны прэдыкат любой палітыкі. Яно робіць высновы з паводзін чорнай скрыні, што азначае, што часам яно будзе паведамляць пра знаходку, якая аказваецца наўмысна публічнымі дадзенымі (табліца маркетынгавай рассылкі, публічны каталог тавараў). Справаздача FixVibe пазначае іх як сярэдняй упэўненасці, калі сканер не можа адназначна вызначыць намер — праглядзіце імя табліцы і вырашыце.

Чатыры формы зламанага RLS, якія вырабляюць ШІ-інструменты

Калі вы скіроўваеце Cursor, Claude Code, Lovable або Bolt на Supabase, тыя ж чатыры зламаныя шаблоны RLS з'яўляюцца ў тысячах праграм. Кожны з іх праходзіць праверку тыпаў, кампілюецца і выпускаецца:

Форма 1: RLS ніколі не быў уключаны

Найбольш распаўсюджаны рэжым адмовы. Міграцыя стварае табліцу, але распрацоўшчык (або ШІ-інструмент) забывае ALTER TABLE ... ENABLE ROW LEVEL SECURITY. PostgREST з радасцю выдае ўсю табліцу любому з ключом anon. Выпраўленне: ALTER TABLE public.[name] ENABLE ROW LEVEL SECURITY; ALTER TABLE public.[name] FORCE ROW LEVEL SECURITY;. FORCE неабавязковае — без яго ўладальнік табліцы (і любая роля з валоданнем табліцай) абыходзіць RLS.

sql

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

Форма 2: RLS уключаны, без палітык

Больш тонкая адмова. RLS уключаны, але палітыкі не напісаны. Па змаўчанні ў PostgreSQL — забарона, таму аўтэнтыфікаваныя карыстальнікі нічога не бачаць — і распрацоўшчык дадае USING (true), каб праграма працавала, што дазваляе ўсім чытаць усё. Выпраўленне: напішыце палітыку, абмежаваную auth.uid(): CREATE POLICY "select_own" ON public.[name] FOR SELECT USING (auth.uid() = user_id); і адпаведную палітыку INSERT/UPDATE/DELETE.

sql

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

Форма 3: Палітыка параўноўвае слупок з самім сабой

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: Палітыка на SELECT, але не на INSERT/UPDATE

Распрацоўшчык блакуе чытанні, але забывае пра запісы. Палітыкі RLS — пакамандныя. FOR SELECT абараняе толькі чытанні; ананімны кліент усё яшчэ можа выканаць INSERT, калі ніякая палітыка не адхіляе яго. Выпраўленне: напішыце палітыку для кожнай каманды або выкарыстоўвайце FOR ALL з відавочнымі сказамі USING і WITH CHECK.

Як працуе сканер Supabase RLS ад FixVibe

Праверка baas.supabase-rls запускаецца ў тры этапы, кожны з відавочнымі ўзроўнямі ўпэўненасці:

Этап 1 — зняцце адбіткаў. Сканер абыходзіць разгорнутую праграму, разбірае яе JavaScript-бандл і вылучае URL праекта Supabase і ключ anon з канфігурацыі часу выканання. Ніякага здагадвання DNS, ніякага брутфорсу — ён чытае тое, што чытае браўзер.
Этап 2 — выяўленне схемы. Адзіны GET /rest/v1/ з ключом anon вяртае схему OpenAPI для кожнай табліцы, якую можа бачыць роля anon. Сканер запісвае імёны табліц, але не чытае дадзеныя радкоў на гэтым этапе.
Этап 3 — зонды чытання і запісу. Для кожнай выяўленай табліцы сканер выдае адзін ананімны SELECT з limit=1. Калі вяртаюцца радкі, RLS дазваляе. Сканер спыняецца тут — ён не пералічвае радкі, не разбівае на старонкі, не змяняе дадзеныя. Зонды INSERT абмежаваны пацверджаным валоданнем даменам і відавочным удзелам; яны ніколі не запускаюцца супраць непацверджаных мэт.

Кожная знаходка пастаўляецца з дакладным URL запыту, статусам адказу, формай адказу (толькі загалоўкі) і імем табліцы. Падказка выпраўлення ШІ ўнізе знаходкі — гэта блок SQL для капіявання-устаўкі, які вы запускаеце ў рэдактары SQL Supabase.

Што рабіць, калі сканер знаходзіць нешта

Кожная знаходка RLS — гэта надзвычайная сітуацыя ў часе выканання. Публічныя канчатковыя кропкі PostgREST сканіруюцца зламыснікамі за хвіліны. Паслядоўнасць выпраўлення механічная:

Праверце кожную табліцу. Запусціце SELECT schemaname, tablename, rowsecurity FROM pg_tables WHERE schemaname = 'public'; у рэдактары SQL Supabase. Любы радок з rowsecurity = false — гэта праблема.
Уключыце RLS на кожнай публічнай табліцы. Па змаўчанні выкарыстоўвайце ENABLE ROW LEVEL SECURITY і FORCE ROW LEVEL SECURITY на кожнай створанай табліцы — зрабіце гэта шаблонам міграцыі.
Пішыце палітыкі пакамандна. Не выкарыстоўвайце FOR ALL USING (true). Пішыце відавочныя палітыкі для SELECT, INSERT, UPDATE, DELETE — кожную абмежаваную auth.uid() або слупком org-id з auth.jwt().
Праверце з другім акаўнтам. Зарэгіструйцеся як іншы карыстальнік, паспрабуйце прачытаць запісы іншага карыстальніка праз REST API напрамую. Калі адказ — 200, палітыка зламана.
Прасканіруйце паўторна. Пасля прымянення выпраўлення запусціце паўторнае сканаванне FixVibe супраць таго ж URL. Знаходка baas.supabase-rls павінна знікнуць.

sql

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

Як гэта параўноўваецца з іншымі сканерамі

Большасць агульных DAST-інструментаў (Burp Suite, OWASP ZAP, Nessus) не ведаюць, што такое PostgREST. Яны абыдуць вашу праграму, праігнаруюць шлях /rest/v1/ і паведамяць пра HTML-старонкі, якія яны разумеюць. Snyk і Semgrep — гэта інструменты статычнага аналізу — яны знаходзяць файлы міграцый у вашым рэпазіторыі з адсутнымі выклікамі RLS, але яны не могуць даказаць, што разгорнутая база дадзеных няправільна наладжана. FixVibe знаходзіцца ў гэтым прамежку: пасіўны, BaaS-абазнаны, засяроджаны на тым, што неаўтарызаваны зламыснік можа даказаць з публічнага URL.

Часта задаваныя пытанні

Ці будзе сканер чытаць або змяняць мае дадзеныя?

Не. Пасіўныя сканаванні выдаюць максімум адзін SELECT ... limit=1 на кожную выяўленую табліцу, каб пацвердзіць, ці дазваляе RLS ананімныя чытанні. Сканер запісвае форму адказу, а не змесціва радкоў. Зонды INSERT, UPDATE і DELETE абмежаваны пацверджаным валоданнем даменам і ніколі не запускаюцца супраць непацверджаных мэт.

Ці будзе гэта працаваць, калі мой праект Supabase прыпынены або на карыстальніцкім дамене?

Прыпыненыя праекты вяртаюць 503 на кожны запыт — сканер паведамляе, што праект недасягальны. Карыстальніцкія дамены працуюць, пакуль разгорнутая праграма ўсё яшчэ загружае кліент SDK Supabase у браўзеры; сканер вылучае URL праекта з бандла ў любым выпадку.

А што, калі мой ключ anon ратаваны або мой публікаваны ключ змяніўся?

Запусціце сканаванне зноў. Сканер паўторна вылучае ключ з бягучага бандла пры кожным запуску. Ратацыя анулюе толькі папярэднюю справаздачу, а не стан палітыкі базы дадзеных.

Ці правярае сканер новую мадэль публікаванага ключа Supabase (<code>sb_publishable_*</code>)?

Так. Дэтэктар распазнае як састарэлыя JWT anon, так і новыя ключы sb_publishable_* і ставіцца да іх аднолькава — абодва прызначаны быць публічнымі і абодва пакідаюць RLS як адзіную лінію абароны.

Наступныя крокі

Запусціце бясплатнае сканаванне FixVibe супраць вашага прадукцыйнага URL — праверка baas.supabase-rls уключана на кожным тарыфе, у тым ліку на бясплатным. Для больш глыбокага агляду таго, што яшчэ можа выцякаць з праекта Supabase, гл. Ключ сэрвіснай ролі Supabase, раскрыты ў JavaScript і Кантрольны спіс бяспекі сховішча Supabase. Для агульнага агляду па ўсіх пастаўшчыках BaaS прачытайце Сканер няправільных налад BaaS.