---
title: "Supabase exposed schemas: ko atver šis saraksts"
description: "Ko nozīmē Supabase exposed schemas, kā mana drošības pārbaude vērtē papildu shēmas un viens SQL vaicājums, kas atrod tabulas bez RLS."
url: "https://madsalt.tech/lv/notes/supabase-exposed-schemas/"
author: "Denys Zaichenko"
language: "lv"
published: 2026-10-22
---

# Supabase exposed schemas: ko atver šis saraksts

Ī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](https://madsalt.tech/lv/tools/supabase-security-check/), 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](https://supabase.com/docs/guides/api/using-custom-schemas) saka, ka `public` ir atklāta pēc noklusējuma. Pieprasījums uz shēmu ārpus saraksta tiek noraidīts, un [PostgREST](https://docs.postgrest.org/en/stable/references/api/schemas.html) 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](https://supabase.com/docs/guides/database/postgres/row-level-security) 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.](https://madsalt.tech/charts/lv/supabase-exposed-schemas.svg)

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

```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;
```

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:

```text
 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](https://madsalt.tech/lv/blog/lovable-app-security-checklist/), bet [kā es testēju Supabase RLS](https://madsalt.tech/lv/blog/how-to-test-supabase-rls/) parāda, kā pierādīt, ka politikas strādā.