---
title: "Supabase exposed schemas: čo všetko zoznam sprístupní"
description: "Čo v Supabase znamená nastavenie Exposed schemas, ako extra schémy hodnotí môj bezpečnostný checker a jeden SQL dotaz, ktorý nájde tabuľky bez RLS."
url: "https://madsalt.tech/sk/notes/supabase-exposed-schemas/"
author: "Denys Zaichenko"
language: "sk"
published: 2026-10-22
---

# Supabase exposed schemas: čo všetko zoznam sprístupní

TL;DR

Zoznam Exposed schemas v Supabase určuje, ktoré schémy Data API ponúka každému, kto má váš verejný kľúč. Predvolené sú `public` a `graphql_public`. Každá tabuľka, view a funkcia v schéme na tomto zozname musí mať vlastné granty a RLS, takže každá ďalšia schéma je ďalšia plocha na obranu. Držte zoznam krátky a kontrolujte ho ako prvý.

Postavil som zadarmo [bezpečnostný checker pre Supabase](https://madsalt.tech/sk/tools/supabase-security-check/) a zoznam Exposed schemas je jedna z prvých vecí, ktoré číta. Keď sa ma niekto spýta, aký bezpečný je jeho projekt na Supabase, začínam práve týmto nastavením.

## Čo v Supabase znamená „exposed" schéma?

Supabase vystavuje vašu databázu cez REST pomocou PostgREST. PostgREST odpovedá iba za schémy zo svojho zoznamu `db_schema`, ktorý upravíte v Dashboarde v Project Settings → Data API → Exposed schemas. V konfigurácii projektu, ktorú som si pozeral, bola hodnota `public,graphql_public` a [sprievodca vlastnými schémami](https://supabase.com/docs/guides/api/using-custom-schemas) od Supabase uvádza, že `public` je vystavené v predvolenom stave. Požiadavka na schému mimo zoznamu je odmietnutá a [PostgREST](https://docs.postgrest.org/en/stable/references/api/schemas.html) v ňom nikdy nepovolí `pg_catalog` ani `information_schema`.

## Prečo na tom zozname záleží?

Všetko vnútri vystavenej schémy je dosiahnuteľné verejným kľúčom: tabuľky, views aj funkcie. [Sprievodca RLS](https://supabase.com/docs/guides/database/postgres/row-level-security) od Supabase to hovorí bez obalu: tabuľka vo vystavenej schéme bez RLS je čitateľná aj zapisovateľná pre akúkoľvek rolu, ktorá na ňu má grant. Schéma, ktorá na zozname nie je, cez API dosiahnuteľná nie je vôbec.

Ďalšia schéma teda nie je neutrálna zmena. Ak na zoznam pridáte `storage` alebo `vault`, interné tabuľky sa dostanú na dosah Data API. Ak pridáte vlastnú schému, každá tabuľka v nej potrebuje rovnakú starostlivosť ako `public`.

![Čo otvorí extra vystavená schéma. Jedna anon požiadavka, pred úpravou zoznamu a po nej. Pred: extra schéma je vystavená: anon požiadavka → Data API → extra schéma → tabuľka bez RLS čitateľná; Po: iba public a graphql_public: anon požiadavka → Data API → iba predvolené schémy → RLS na všetkých tabuľkách.](https://madsalt.tech/charts/sk/supabase-exposed-schemas.svg)

*Z pravidiel bezpečnostného checkera Supabase a dokumentácie Supabase Data API, 22. októbra 2026.*

## Ako checker zoznam hodnotí?

Kontrola sa volá `extra_exposed_schemas`. Za extra sa počíta všetko okrem `public` a `graphql_public`, a potom:

- Interná schéma Supabase na zozname (`auth`, `storage`, `realtime`, `vault`, `extensions` a podobné) je **fail, vysoká závažnosť**.
- Iba vlastné schémy, napríklad `api`, dajú **varovanie, stredná závažnosť**.
- Bez extra schém kontrola prejde.

Zoznam riadi aj ďalšie kontroly. Tabuľky s vypnutým RLS, zápisové granty pre anon, politiky, ktoré vždy platia, views bez `security_invoker` a funkcie `SECURITY DEFINER`, ktoré anon môže volať, sa hlásia iba pre vystavené schémy, pretože práve tam na ne verejný kľúč dosiahne.

## Ako bezpečne používať vlastnú schému?

Vlastná schéma je legitímny vzor: sprievodca [Securing your API](https://supabase.com/docs/guides/api/securing-your-api) od Supabase popisuje samostatnú schému, napríklad `api`, ako spôsob, ako vystavenú plochu ľahšie rozpoznať a auditovať, zatiaľ čo interné tabuľky zostanú v schémach, ktoré vystavené nie sú. Funguje to na dva kroky a [sprievodca vlastnými schémami](https://supabase.com/docs/guides/api/using-custom-schemas) uvádza oba: pridajte schému do Exposed schemas a potom dajte rolám `anon`, `authenticated` a `service_role` oprávnenie `usage` na schému a oprávnenia na jej objekty.

Príklad v sprievodcovi udeľuje `ALL` na každú tabuľku. Taký riadok by som neskopíroval tak, ako je. Sprievodca Securing your API hovorí, aby každá rola dostala iba minimum, ktoré potrebuje, a aby sa RLS zapnulo na každej tabuľke, ktorú vystavíte. Granty rozhodujú, či sa rola tabuľky môže dotknúť, politiky rozhodujú, ktoré riadky uvidí.

Jedna samostatná zmena: Supabase [prestáva nové tabuľky v `public` automaticky sprístupňovať Data API](https://supabase.com/changelog/45329-breaking-change-tables-not-exposed-to-data-and-graphql-api-automatically). Pre nové projekty je to predvolené od 30. mája 2026 a na existujúce projekty sa použije 30. októbra 2026, pričom existujúce tabuľky si granty ponechajú. To je vrstva grantov. Na tom, ktoré schémy sú na zozname, to nič nemení.

## Ako skontrolovať vlastný projekt?

Otvorte Project Settings → Data API a prečítajte si Exposed schemas. Ak je tam viac než `public` a `graphql_public`, spýtajte sa, načo je každá extra schéma.

Potom vypíšte tabuľky v týchto schémach, ktoré majú RLS vypnuté, a zistite, či ich `anon` už teraz môže čítať:

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

Spustil som ho na skúšobnom Postgrese 17 so schémou `api`, kde bola jedna tabuľka s RLS a jedna bez, a s tabuľkou v `public` bez RLS. Vrátil iba tie dve bez RLS:

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

Každý riadok, kde je `anon_can_select` pravda, je tabuľka, ktorú môže čítať ktokoľvek s vaším verejným kľúčom, kým nezapnete RLS alebo nevezmete grant späť. Dotaz pokrýva iba tabuľky. Views a funkcie chcú vlastnú kontrolu, ktorú robí môj [checklist bezpečnosti aplikácie z Lovable](https://madsalt.tech/sk/blog/lovable-app-security-checklist/), a [ako testujem Supabase RLS](https://madsalt.tech/sk/blog/how-to-test-supabase-rls/) ukazuje, ako dokázať, že politiky fungujú.