Supabase exposed schemas: mitä lista avaa

Rakensin ilmaisen Supabase-tietoturvatarkistuksen, ja Exposed schemas -lista on yksi ensimmäisistä asioista, jotka se lukee. Kun joku kysyy, kuinka turvallinen Supabase-projekti on, aloitan tästä asetuksesta.

Mitä “exposed” tarkoittaa Supabasessa ja mitä Data API tekee?

Supabase tarjoaa tietokantasi REST-rajapintana PostgREST:n kautta. PostgREST vastaa vain db_schema-listansa skeemoille, jota muokkaat Dashboardissa kohdassa Project Settings → Data API → Exposed schemas. Tarkastelemassani projektin konfiguraatiossa arvo oli public,graphql_public, ja Supabasen custom schemas -opas sanoo, että public on julkaistu oletuksena. Pyyntö listan ulkopuoliseen skeemaan hylätään, eikä PostgREST salli listalla koskaan pg_catalog- tai information_schema-skeemaa.

Miksi Exposed schemas -lista on tietoturvan kannalta tärkeä?

Kaikki julkaistun skeeman sisällä on tavoitettavissa julkisella avaimella: taulut, viewt ja funktiot. Supabasen RLS-opas on suorasanainen: julkaistun skeeman taulu ilman RLS:ää on luettavissa ja kirjoitettavissa jokaisella roolilla, jolla on siihen oikeus. Skeemaa, joka ei ole listalla, ei voi tavoittaa API:n kautta lainkaan.

Ylimääräinen skeema ei siis ole neutraali muutos. Lisää storage tai vault listalle, ja sisäiset taulut ovat Data API:n ulottuvilla. Lisää oma skeemasi, ja jokainen sen taulu vaatii saman huolellisuuden kuin public.

Miten tarkistus arvioi ylimääräiset skeemat?

Tarkistuksen nimi on extra_exposed_schemas. Ylimääräiseksi lasketaan kaikki paitsi public ja graphql_public, ja sitten:

• Supabasen sisäinen skeema listalla (auth, storage, realtime, vault, extensions ja vastaavat) on fail, korkea vakavuus (high).
• Pelkät omat skeemat, esimerkiksi api, antavat varoituksen (warning), keskitason vakavuus (medium).
• Ilman ylimääräisiä skeemoja tarkistus menee läpi.

Sama lista ohjaa myös muita tarkistuksia. Taulut ilman RLS:ää, anonin kirjoitusoikeudet, aina tosi -politiikat, ilman security_invoker-asetusta olevat viewt ja SECURITY DEFINER -funktiot, joita anon voi kutsua, raportoidaan vain julkaistuista skeemoista, koska julkinen avain yltää niihin juuri siellä.

Miten oman skeeman voi ottaa turvallisesti käyttöön?

Oma skeema on aivan hyväksyttävä malli: Supabasen Securing your API -opas kuvaa erillisen skeeman, kuten api, keinona tehdä julkaistusta pinta-alasta helpommin tunnistettava ja auditoitava, kun sisäiset taulut pysyvät skeemoissa, joita ei ole julkaistu. Kaksi vaihetta saa sen toimimaan, ja custom schemas -opas antaa molemmat: lisää skeema Exposed schemas -listalle, anna sitten rooleille anon, authenticated ja service_role oikeus usage siihen sekä oikeudet sen objekteihin.

Oppaan esimerkki antaa ALL jokaiseen tauluun. En kopioisi sitä riviä sellaisenaan. Securing your API -opas sanoo antamaan jokaiselle roolille vähimmäisoikeudet, jotka se tarvitsee, ja ottamaan RLS:n käyttöön jokaisessa julkaisemassasi taulussa. Oikeudet (grants) ratkaisevat, saako rooli koskea tauluun, politiikat ratkaisevat, mihin riveihin.

Yksi erillinen muutos: Supabase lopettaa uusien public-taulujen antamisen Data API:lle automaattisesti. Uusissa projekteissa siitä tuli oletus 30. toukokuuta 2026 alkaen ja olemassa oleviin projekteihin se otetaan käyttöön 30. lokakuuta 2026, ja olemassa olevat taulut säilyttävät oikeutensa. Se on oikeuksien (grants) kerros. Se ei muuta sitä, mitkä skeemat ovat listalla.

Miten tarkistat oman projektisi?

Avaa Project Settings → Data API ja lue Exposed schemas. Jos siellä on enemmän kuin public ja graphql_public, kysy, mihin kutakin ylimääräistä skeemaa tarvitaan.

Listaa sitten näiden skeemojen taulut, joissa RLS on pois päältä, ja se, voiko anon jo lukea ne:

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;

Ajoin sen väliaikaisella Postgres 17:llä, jossa oli api-skeema yhdellä RLS:llä suojatulla ja yhdellä ilman RLS:ää olevalla taululla, sekä public-taulu ilman RLS:ää. Se palautti vain nämä kaksi ilman RLS:ää:

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

Jokainen rivi, jossa anon_can_select on tosi, on taulu, jonka kuka tahansa julkisen avaimesi haltija voi lukea, kunnes otat RLS:n käyttöön tai peruutat oikeuden. Kysely kattaa vain taulut. Viewt ja funktiot vaativat oman tarkastelunsa, jonka käy läpi Lovable-sovelluksen tietoturvatarkistuslistani, ja miten testaan Supabase RLS:ää näyttää, miten todistat politiikkojen toimivan.