---
title: "Supabase exposed schemas: mida see nimekiri avab"
description: "Mida tähendab Supabase exposed schemas, kuidas mu turvakontroll lisaskeeme hindab ja üks SQL-päring, mis leiab tabelid ilma RLS-ita."
url: "https://madsalt.tech/et/notes/supabase-exposed-schemas/"
author: "Denys Zaichenko"
language: "et"
published: 2026-10-22
---

# Supabase exposed schemas: mida see nimekiri avab

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](https://madsalt.tech/et/tools/supabase-security-check/) 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](https://supabase.com/docs/guides/api/using-custom-schemas) ütleb, et `public` on vaikimisi avaldatud. Päring skeemi kohta, mida nimekirjas pole, lükatakse tagasi, ja [PostgREST](https://docs.postgrest.org/en/stable/references/api/schemas.html) 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](https://supabase.com/docs/guides/database/postgres/row-level-security) 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.](https://madsalt.tech/charts/et/supabase-exposed-schemas.svg)

*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](https://supabase.com/docs/guides/api/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](https://supabase.com/docs/guides/api/using-custom-schemas): 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](https://supabase.com/changelog/45329-breaking-change-tables-not-exposed-to-data-and-graphql-api-automatically). 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:

```sql
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:

```text
 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](https://madsalt.tech/et/blog/lovable-app-security-checklist/), ja [kuidas ma Supabase'i RLS-i testin](https://madsalt.tech/et/blog/how-to-test-supabase-rls/) näitab, kuidas tõestada, et poliitikad töötavad.