Liigu sisu juurde

Supabase exposed schemas: mida see nimekiri avab

Supabase

Vaata MarkdowninaAva rakenduses ClaudeAva rakenduses ChatGPTAva rakenduses Perplexity

Küsimus kopeeritakse ka. Kui vestlus avaneb tühjana, kleepige see sisse.

Lühidalt

Supabase’i nimekiri Exposed schemas otsustab, milliseid skeeme Data API serveerib igaühele, kellel on teie avalik võti. Vaikimisi on need public ja graphql_public. Igal nimekirjas oleva skeemi tabelil, view’l ja funktsioonil peavad olema oma õigused (grants) ja RLS, seega on iga lisaskeem veel üks kaitsta vajav pind. Hoidke nimekiri lühike ja kontrollige seda esimesena.

Ehitasin tasuta Supabase’i turvakontrolli ja Exposed schemas nimekiri on üks esimesi asju, mida see loeb. Kui keegi küsib, kui turvaline on Supabase’i projekt, alustan just sellest seadistusest.

Mida tähendab Supabase’is “exposed” ja mida Data API teeb?

Supabase serveerib teie andmebaasi REST-ina PostgREST-i kaudu. PostgREST vastab ainult oma db_schema nimekirjas olevate skeemide eest, mida muudate Dashboardis kohas Project Settings → Data API → Exposed schemas. Vaadatud projekti konfiguratsioonis oli väärtus public,graphql_public ning Supabase’i custom schemas juhend ütleb, et public on vaikimisi avaldatud. Päring skeemi kohta, mida nimekirjas pole, lükatakse tagasi, ja PostgREST ei luba selles kunagi pg_catalog ega information_schema.

Miks see nimekiri turvalisuse jaoks loeb?

Kõik avaldatud skeemi sees on avaliku võtmega kättesaadav: tabelid, view’d ja funktsioonid. Supabase’i RLS-i juhend on selge: avaldatud skeemi tabel ilma RLS-ita on loetav ja kirjutatav iga rolli poolt, millel on sellele õigus. Skeemile, mida nimekirjas pole, ei pääse API kaudu üldse ligi.

Seega pole lisaskeem neutraalne muudatus. Lisate nimekirja storage või vault ja sisemised tabelid on Data API käeulatuses. Lisate oma skeemi ja iga selle tabel vajab sama hoolt nagu public.

Mida avaldatud lisaskeem avab. Üks anon-päring enne ja pärast nimekirja kärpimist. Enne: lisaskeem on avaldatud: anon-päring → Data API → lisaskeem → RLS-ita tabel loetav; Pärast: ainult public ja graphql_public: anon-päring → Data API → ainult vaikeskeemid → RLS kõigil tabelitel.
Supabase'i turvakontrolli reeglitest ja Supabase'i Data API dokumentatsioonist, 22. oktoober 2026.

Kuidas kontroll lisaskeeme hindab?

Kontrolli nimi on extra_exposed_schemas. Lisaskeemiks loetakse kõik peale public ja graphql_public, seejärel:

  • Supabase’i sisemine skeem nimekirjas (auth, storage, realtime, vault, extensions ja sarnased) on fail, kõrge tõsidus (high).
  • Ainult oma skeemid, näiteks api, annavad hoiatuse (warning), keskmine tõsidus (medium).
  • Ilma lisaskeemideta kontroll läbitakse.

Sama nimekiri juhib ka teisi kontrolle. Tabelid ilma RLS-ita, anon-kirjutusõigused, alati tõesed poliitikad, security_invoker’ita view’d ja SECURITY DEFINER funktsioonid, mida anon saab kutsuda, raporteeritakse ainult avaldatud skeemide kohta, sest just seal avalik võti neile ligi pääseb.

Kuidas oma skeemi turvaliselt kasutada?

Oma skeem on legitiimne muster: Supabase’i juhend Securing your API kirjeldab pühendatud skeemi, näiteks api, kui viisi muuta avaldatud pind lihtsamini tuvastatavaks ja auditeeritavaks, hoides sisemised tabelid skeemides, mis pole avaldatud. Kaks sammu panevad selle tööle ja mõlemad annab custom schemas juhend: lisage skeem nimekirja Exposed schemas, seejärel andke rollidele anon, authenticated ja service_role õigus usage ning õigused selle objektidele.

Juhendi näide annab ALL igale tabelile. Mina seda rida sellisena ei kopeeriks. Securing your API juhend ütleb anda igale rollile minimaalse vajaliku ja lülitada RLS sisse igal avaldataval tabelil. Õigused (grants) otsustavad, kas roll saab tabelit puudutada, poliitikad otsustavad, milliseid ridu.

Üks eraldi muudatus: Supabase lõpetab uute public tabelite automaatse andmise Data API-le. Uutes projektides sai see vaikeväärtuseks 30. maist 2026 ja olemasolevatele projektidele rakendatakse seda 30. oktoobril 2026, olemasolevad tabelid säilitavad oma õigused. See on õiguste (grants) kiht. See ei muuda, millised skeemid on nimekirjas.

Kuidas oma projekti kontrollida?

Avage Project Settings → Data API ja lugege Exposed schemas. Kui seal on rohkem kui public ja graphql_public, küsige, milleks iga lisaskeem vajalik on.

Seejärel loetlege nende skeemide tabelid, millel RLS on väljas, ja see, kas anon saab neid juba lugeda:

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;

Käivitasin selle ajutisel Postgres 17-l, kus oli api skeem ühe RLS-iga ja ühe RLS-ita tabeliga, ning public tabel ilma RLS-ita. See tagastas ainult need kaks ilma RLS-ita:

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

Iga rida, kus anon_can_select on tõene, on tabel, mida igaüks teie avaliku võtmega saab lugeda, kuni lülitate RLS-i sisse või võtate õiguse tagasi. Päring katab ainult tabelid. View’d ja funktsioonid vajavad eraldi pilku, mille läbib samm-sammult mu Lovable’i rakenduse turvakontrollnimekiri, ja kuidas ma Supabase’i RLS-i testin näitab, kuidas tõestada, et poliitikad töötavad.

© 2026 Denys Zaichenko. Algne artikkel: https://madsalt.tech/et/notes/supabase-exposed-schemas/