Pāriet uz saturu

Supabase exposed schemas: ko atver šis saraksts

Supabase

Skatīt kā MarkdownAtvērt pakalpojumā ClaudeAtvērt pakalpojumā ChatGPTAtvērt pakalpojumā Perplexity

Jautājums tiek arī nokopēts. Ja tērzēšana atveras tukša, ielīmējiet to.

Īsumā

Supabase sarakstā Exposed schemas ir noteikts, kuras shēmas Data API sniedz ikvienam, kam ir jūsu publiskā atslēga. Pēc noklusējuma tās ir public un graphql_public. Katrai tabulai, skatam un funkcijai shēmā, kas ir sarakstā, vajadzīgas savas tiesības (grants) un RLS, tāpēc katra papildu shēma ir vēl viena virsma, kas jāaizsargā. Turiet sarakstu īsu un pārbaudiet to vispirms.

Es izveidoju bezmaksas Supabase drošības pārbaudi, un Exposed schemas saraksts ir viena no pirmajām lietām, ko tā nolasa. Kad kāds jautā, cik droši ir Supabase projekts, es sāku tieši ar šo iestatījumu.

Ko nozīmē “exposed” Supabase un ko dara Data API?

Supabase sniedz jūsu datubāzi kā REST, izmantojot PostgREST. PostgREST atbild tikai par shēmām savā db_schema sarakstā, ko rediģē Dashboard sadaļā Project Settings → Data API → Exposed schemas. Projekta konfigurācijā, ko skatījos, vērtība bija public,graphql_public, un Supabase custom schemas ceļvedis saka, ka public ir atklāta pēc noklusējuma. Pieprasījums uz shēmu ārpus saraksta tiek noraidīts, un PostgREST nekad neļauj tajā iekļaut pg_catalog vai information_schema.

Kāpēc šis saraksts ir svarīgs drošībai?

Viss atklātajā shēmā ir sasniedzams ar publisko atslēgu: tabulas, skati un funkcijas. Supabase RLS ceļvedis ir tiešs: tabula atklātā shēmā bez RLS ir lasāma un rakstāma ikvienai lomai, kurai uz to ir piešķirtas tiesības. Shēmu, kas nav sarakstā, caur API nevar sasniegt vispār.

Tāpēc papildu shēma nav neitrāla izmaiņa. Pievienojiet sarakstam storage vai vault, un iekšējās tabulas nonāk Data API sasniedzamībā. Pievienojiet savu shēmu, un katrai tās tabulai vajag tādu pašu uzmanību kā public.

Ko atver papildu atklātā shēma. Viens anon pieprasījums pirms un pēc saraksta saīsināšanas. Pirms: papildu shēma ir atklāta: anon pieprasījums → Data API → papildu shēma → tabula bez RLS lasāma; Pēc: tikai public un graphql_public: anon pieprasījums → Data API → tikai noklusējuma shēmas → RLS visām tabulām.
No Supabase drošības pārbaudes noteikumiem un Supabase Data API dokumentācijas, 2026. gada 22. oktobris.

Kā pārbaude vērtē papildu shēmas?

Pārbaudi sauc extra_exposed_schemas. Par papildu skaitās viss, izņemot public un graphql_public, un tad:

  • Supabase iekšēja shēma sarakstā (auth, storage, realtime, vault, extensions un līdzīgas) ir fail, augsts svarīgums (high).
  • Tikai pašu veidotas shēmas, piemēram, api, dod brīdinājumu (warning), vidēju svarīgumu (medium).
  • Ja papildu shēmu nav, pārbaude izdodas.

Tas pats saraksts nosaka arī citas pārbaudes. Tabulas ar izslēgtu RLS, anon rakstīšanas tiesības, vienmēr patiesas politikas, skati bez security_invoker un SECURITY DEFINER funkcijas, ko var izsaukt anon, tiek ziņotas tikai atklātajām shēmām, jo tieši tur publiskā atslēga tām piekļūst.

Kā droši izmantot savu shēmu?

Pašu veidota shēma ir likumīgs paņēmiens: Supabase ceļvedis Securing your API apraksta atsevišķu shēmu, piemēram, api, kā veidu, kā atklāto virsmu padarīt vieglāk atpazīstamu un auditējamu, bet iekšējās tabulas turēt shēmās, kas nav atklātas. Lai tas strādātu, vajag divus soļus, un abus dod custom schemas ceļvedis: pievienojiet shēmu sarakstam Exposed schemas, tad piešķiriet anon, authenticated un service_role tiesības usage uz to, kā arī tiesības uz tās objektiem.

Ceļveža piemērs piešķir ALL uz katru tabulu. Es šo rindu nekopētu tādu, kāda tā ir. Securing your API ceļvedis liek katrai lomai dot minimumu, kas tai vajadzīgs, un ieslēgt RLS katrai tabulai, ko atklājat. Tiesības (grants) nosaka, vai loma var pieskarties tabulai, politikas nosaka, kuras rindas.

Vēl viena atsevišķa izmaiņa: Supabase pārstāj automātiski piešķirt jaunās public tabulas Data API. Jauniem projektiem tā kļuva par noklusējumu no 2026. gada 30. maija, bet esošajiem projektiem to piemēros 2026. gada 30. oktobrī, un esošās tabulas saglabā savas tiesības. Tas ir tiesību (grants) slānis. Tas nemaina, kuras shēmas ir sarakstā.

Kā pārbaudīt savu projektu?

Atveriet Project Settings → Data API un izlasiet Exposed schemas. Ja tur ir vairāk nekā public un graphql_public, pajautājiet, kam kalpo katra papildu shēma.

Tad izvelciet šo shēmu tabulas ar izslēgtu RLS un to, vai anon jau var tās lasīt:

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;

Es to palaidu uz pagaidu Postgres 17 ar api shēmu, kurā bija viena tabula ar RLS un viena bez, kā arī public tabulu bez RLS. Tas atgrieza tikai tās divas, kurām RLS nav:

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

Katra rinda ar anon_can_select true ir tabula, ko ikviens ar jūsu publisko atslēgu var lasīt, kamēr neieslēdzat RLS vai neatsaucat tiesības. Vaicājums aptver tikai tabulas. Skatiem un funkcijām vajag atsevišķu pārbaudi, ko soli pa solim iziet mans Lovable lietotnes drošības kontrolsaraksts, bet kā es testēju Supabase RLS parāda, kā pierādīt, ka politikas strādā.

© 2026 Denys Zaichenko. Oriģinālais raksts: https://madsalt.tech/lv/notes/supabase-exposed-schemas/