Supabase exposed schemas: ką atveria šis sąrašas

Sukūriau nemokamą Supabase saugos tikrintuvą, o Exposed schemas sąrašas yra vienas pirmųjų dalykų, kuriuos jis skaito. Kai manęs paklausia, kiek saugus Supabase projektas, pradedu būtent nuo šio nustatymo.

Ką Supabase reiškia „exposed” schema?

Supabase pateikia jūsų duomenų bazę per REST su PostgREST. PostgREST atsako tik už schemas iš savo db_schema sąrašo, kurį keičiate Dashboard skiltyje Project Settings → Data API → Exposed schemas. Projekto konfigūracijoje, kurią mačiau, reikšmė buvo public,graphql_public, o Supabase vadove apie savo schemas rašoma, kad public pateikiama pagal numatytuosius nustatymus. Užklausa dėl schemos ne iš sąrašo atmetama, o PostgREST niekada neleidžia sąraše turėti pg_catalog ar information_schema.

Kodėl šis sąrašas svarbus?

Viskas pateiktoje schemoje pasiekiama viešuoju raktu: lentelės, view ir funkcijos. Supabase RLS vadovas sako tiesiai: lentelė pateiktoje schemoje be RLS yra skaitoma ir rašoma bet kuriai rolei, turinčiai į ją teisę. Schema, kurios sąraše nėra, per API nepasiekiama visai.

Taigi papildoma schema nėra neutralus pakeitimas. Įtraukus į sąrašą storage ar vault, vidinės lentelės atsiduria Data API pasiekiamumo ribose. Įtraukus savo schemą, kiekvienai joje esančiai lentelei reikia tokio pat dėmesio kaip public.

Kaip tikrintuvas vertina sąrašą?

Patikra vadinasi extra_exposed_schemas. Papildoma laikoma viskas, išskyrus public ir graphql_public, toliau:

• Vidinė Supabase schema sąraše (auth, storage, realtime, vault, extensions ir panašios) yra fail, aukšta svarba.
• Tik savos schemos, pavyzdžiui api, duoda įspėjimą, vidutinė svarba.
• Be papildomų schemų patikra praeina.

Tas pats sąrašas valdo ir kitas patikras. Lentelės su išjungtu RLS, anon rašymo teisės, visada teisingos politikos, view be security_invoker ir SECURITY DEFINER funkcijos, kurias gali kviesti anon, pranešamos tik pateiktoms schemoms, nes būtent ten viešasis raktas jas pasiekia.

Kaip saugiai naudoti savo schemą?

Sava schema yra teisėtas modelis: Supabase vadove Securing your API atskira schema, pavyzdžiui api, aprašoma kaip būdas pateikiamą paviršių lengviau atpažinti ir tikrinti, o vidines lenteles laikyti schemose, kurios nepateikiamos. Veikia dviem žingsniais, ir abu nurodyti vadove apie savo schemas: pridėkite schemą prie Exposed schemas, tada suteikite rolėms anon, authenticated ir service_role teisę usage į schemą ir teises į jos objektus.

Vadovo pavyzdys suteikia ALL kiekvienai lentelei. Tos eilutės nekopijuočiau tokios, kokia yra. Vadove Securing your API rašoma, kad kiekviena rolė gautų tik tai, ko jai būtina reikia, ir kad RLS būtų įjungtas kiekvienoje pateikiamoje lentelėje. Teisės nusprendžia, ar rolė gali liesti lentelę, o politikos nusprendžia, kurias eilutes.

Dar vienas atskiras pakeitimas: Supabase nebeprideda naujų public lentelių prie Data API automatiškai. Naujiems projektams tai numatytoji tvarka nuo 2026 m. gegužės 30 d., o esamiems projektams bus taikoma 2026 m. spalio 30 d., esamos lentelės teises išsaugo. Tai teisių sluoksnis. Jis nekeičia to, kurios schemos yra sąraše.

Kaip patikrinti savo projektą?

Atidarykite Project Settings → Data API ir perskaitykite Exposed schemas. Jei ten daugiau nei public ir graphql_public, paklauskite, kam skirta kiekviena papildoma schema.

Tada išvardykite tose schemose esančias lenteles su išjungtu RLS ir pažiūrėkite, ar anon jau gali jas skaityti:

select n.nspname as schema,
       c.relname as "table",
       has_table_privilege('anon', c.oid, 'select') as anon_can_select
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
where n.nspname in ('public', 'api')  -- your Exposed schemas
  and c.relkind in ('r', 'p')
  and not c.relrowsecurity
order by 1, 2;

Paleidau ją laikinoje Postgres 17 su schema api, kurioje buvo viena lentelė su RLS ir viena be jo, ir public lentele be RLS. Grąžino tik tas dvi be RLS:

 schema | table  | anon_can_select
--------+--------+-----------------
 api    | orders | t
 public | logs   | t

Kiekviena eilutė, kurioje anon_can_select yra tiesa, yra lentelė, kurią gali skaityti bet kas, turintis jūsų viešąjį raktą, kol neįjungsite RLS arba neatimsite teisės. Užklausa apima tik lenteles. View ir funkcijoms reikia atskiros patikros, ją aprašo mano Lovable programos saugos sąrašas, o kaip testuoju Supabase RLS parodo, kaip įrodyti, kad politikos veikia.