Supabase Data API 2026. október 30-tól: miért nem működik az új tábla GRANT nélkül, és mit ellenőrizzen az AI-val készült alkalmazásban

2026. október 30-tól a Supabase Data API egyetlen új táblát sem lát a public sémában, amíg valaki kifejezetten hozzáférést nem ad neki egy GRANT utasítással. Az a funkció, amelyet az AI eszköz e dátum után épít be az alkalmazásba, ezért az adatok helyett „permission denied” hibát adhat vissza. A Supabase szerint a meglévő táblák megtartják az eddigi jogosultságaikat, így a ma működő alkalmazás magától nem romlik el. A kockázat a következő változtatásban rejlik. Ez azokat az alkalmazásokat érinti, amelyek a supabase-js könyvtáron vagy REST-en keresztül olvassák az adatokat, így a saját Supabase projekthez kötött Lovable és Bolt projekteket is.

Az alábbiakban megtalálja, pontosan mi változik, hogyan derítheti ki, hogy az Ön alkalmazását érinti-e, és mit érdemes ellenőrizni a határidő előtt. Ha egy AI eszközzel készült alkalmazás tágabb értelemben is gondot okoz, kezdje az elsősegély-ellenőrzőlistánkkal vibe-coded weboldalakhoz. Hogy egy AI eszköz miért nem feltétlenül ismeri a tanítása után érkezett változást, azt a Mi az LLM, és mire nem képes az AI című cikk magyarázza el. Ha az AI-val készült alkalmazás hibákat dob, és nem szeretné vakon javítani, nézze meg az AI weboldalak javítása szolgáltatásunkat.

Mi változik a Supabase Data API-ban 2026. október 30-án

A public sémában létrehozott új tábla már nem lesz automatikusan elérhető a Data API-n keresztül, a hozzáférést kifejezett GRANT utasítással kell megadni.

A Data API az a réteg, amelyen keresztül az alkalmazás olvassa és írja az adatokat: az automatikusan generált REST és GraphQL felület, amelyet a supabase-js könyvtár hív. Eddig minden új tábla a public sémában létrehozáskor olvasási, beszúrási, módosítási és törlési jogosultságot kapott az anon, az authenticated és a service_role szerepkör számára. A tábla abban a pillanatban elérhető volt az API-n, amikor létrejött. A Supabase a changelogban közzétett bejelentésében így változtat ezen:

Lépés	Eddig	A változás után
Tábla létrehozása a public sémában	A tábla azonnal elérhető a Data API-n	A tábla létezik, de a Data API nem látja
Hozzáférés az anon, authenticated és service_role szerepkörnek	Automatikusan, alapértelmezett jogosultságokkal	Kötelező, kifejezett GRANT utasítás
RLS bekapcsolása a táblán	Nem változik	Nem változik
RLS szabályok (policies)	Nem változik	Nem változik

A változás három lépésben érkezik. 2026. április 28-tól projekt létrehozásakor be lehetett kapcsolni az új működést. 2026. május 30-tól ez az alapértelmezés minden új projektnél. 2026. október 30-tól minden meglévő projektre érvényes lesz. A bejelentésben szereplő terv szerint a Supabase-nek az aktív projektek tulajdonosai és adminisztrátorai számára szeptember 23-án értesítést, október 23-án pedig utolsó emlékeztetőt kellett küldenie. A bejelentés szerint a saját szerveren futtatott (self-hosted) Supabase telepítéseket a változás nem érinti.

Ha egy táblához hiányzik a jogosultság, az API 42501 kódú hibát ad vissza „permission denied for table” üzenettel, és a hint mezőben pontosan megírja, melyik szerepkörtől milyen jogosultság hiányzik, és melyik utasítás javítja. A Supabase azzal indokolja a változást, hogy ma már nemcsak ember hoz létre táblákat, hanem AI ügynökök, szkriptek és AI platformok is, gyakran úgy, hogy senki sem ellenőrzi a módosítást. Az alapértelmezett jogosultságok így olyan táblákat is elérhetővé tettek, amelyek védelméről valaki megfeledkezett.

Supabase Data API és Lovable vagy Bolt alkalmazás: érinti Önt?

Akkor érinti, ha az alkalmazás a Data API-n keresztül olvassa a táblákat, és a projektbe még kerülnek új táblák.

A Supabase három helyzetet nevez meg, amelyben teendő van: az alkalmazás a Data API-n keresztül olvas vagy ír táblákat a public sémában (supabase-js, más kliens könyvtár vagy közvetlen hívás a /rest/v1/ vagy a /graphql/v1 címre), a migrációk GRANT utasítások nélkül hoznak létre táblákat, vagy egy AI eszköz, illetve szkript hoz létre táblákat, és azt várja, hogy azonnal elérhetők legyenek. Ha viszont az alkalmazás csak közvetlen Postgres-kapcsolaton át kommunikál az adatbázissal (connection string, ORM, saját szerver), a változás nem érinti.

Az AI builderek esetében az dönt, hol futnak valójában az adatok. A Lovable a Supabase-integráció dokumentációja szerint a csatlakoztatott saját projektnél maga tervezi meg a sémát, az Ön jóváhagyása után futtatja a migrációkat, és a kódban a supabase/migrations/ mappába menti őket. Alapértelmezésként azonban a saját beépített backendjét, a Lovable Cloudot használja, amely a Supabase nyílt forráskódú alapjára épül, és a Lovable kezeli. A Bolt a Supabase-integráció súgója szerint az új projekteket saját Bolt adatbázissal hozza létre, a Supabase-t pedig alternatívaként kínálja a Pro és Teams csomagokban.

Az Ön helyzete	Érinti a változás?	Teendő
Saját Supabase projekthez kötött Lovable vagy Bolt	Igen, ha az alkalmazás a Data API-t használja	A migrációk és az új táblák ellenőrzése az alábbi lépések szerint
Saját alkalmazás Supabase-en, supabase-js könyvtárral	Igen	GRANT utasítás minden olyan migrációba, amely táblát hoz létre
Lovable Cloud vagy Bolt adatbázis	A Supabase bejelentése nem említi ezeket a kezelt backendeket	Ellenőrzés az adott eszköz dokumentációjában vagy changelogjában
Közvetlen Postgres-kapcsolat connection stringgel	Nem	Nincs teendő
Self-hosted Supabase	Nem	Nincs teendő

Ha a Supabase-től „affected projects” tárgyú e-mailt kapott, az nem jelenti azt, hogy az alkalmazás október 30-án leáll. A Supabase projekt egyik karbantartója a változásról szóló GitHub-beszélgetésben elmagyarázta, hogy az érintett projektek száma az október 30-i változásra vonatkozik, amikor a meglévő projektekben az új táblákhoz kifejezett jogosultság kell. Szerinte a meglévő táblákat ez nem érinti. A döntés tehát azon múlik, hogy fejleszti-e még tovább a projektet.

Jogosultságok és RLS: két réteg, amelyet nem szabad összekeverni

A GRANT dönti el, hogy egy szerepkör egyáltalán eléri-e a táblát, az RLS pedig azt, hogy mely sorokat látja. Mindkettőre szükség van.

A Supabase a Securing your API útmutatóban ezt a hozzáférés-szabályozás két rétegeként írja le. A jogosultságok határozzák meg, mely szerepkörök érhetnek el egy táblát, nézetet vagy függvényt a Data API-n keresztül. A Row Level Security (RLS) határozza meg, hogy ezek a szerepkörök mely sorokat olvashatják vagy módosíthatják. Az október 30-i változás csak az első réteget érinti. Az RLS ugyanúgy működik tovább.

Ennek a hibának a javításakor más veszély is fenyeget. A „permission denied” hiba egyetlen tömeges utasítással elhallgattatható, amely minden táblához egyszerre ad hozzáférést. Ha azonban a táblán nincs bekapcsolva az RLS, a Supabase dokumentációja szerint bármelyik jogosultsággal rendelkező szerepkör olvashatja és módosíthatja, így az anon szerepkör is, amellyel a be nem jelentkezett látogatók érkeznek. Az RLS alapértelmezésként be van kapcsolva a Dashboardon létrehozott tábláknál. Az SQL szerkesztőből vagy más eszközből származó tábláknál kifejezetten be kell kapcsolni.

A Supabase ezért azt javasolja, hogy három lépést egy egységként kezeljen: a jogosultságok megadását, az RLS bekapcsolását és a szabályokat arról, ki mely sorokat lát. A jogosultságok szerepkörönként adhatók meg, így a névtelen látogató csak olvashatja a táblát, a bejelentkezett felhasználó pedig szerkesztheti is. Ha ezeket a lépéseket szétválasztja, és csak az elsőt végzi el, a hibát kijavítja, de az adatokat a be nem jelentkezett látogatók előtt is megnyitja.

Mit ellenőrizzen október 30. előtt: 6 lépéses folyamat

Az ellenőrzést a határidő előtt végezze el, ne akkor, amikor egy új funkció éles üzemben üres képernyőt mutat.

1. Derítse ki, hogy az alkalmazás használja-e a Data API-t. Keresse a kódban a supabase-js könyvtárat vagy a /rest/v1/ címre irányuló hívásokat. Ha az alkalmazás csak connection stringen át kommunikál az adatbázissal, itt be is fejezheti.
2. Nézze meg a Dashboardot. A Supabase szerint a Data API-n elérhető táblákat a Table Editor jelvénye és a Data API beállításai mutatják, a Security Advisor pedig október 30-ig megjelöli az érintett táblákat, a javító SQL utasítással együtt.
3. Nézze át a migrációkat. Lovable projektben a supabase/migrations/ mappában találja őket. A public sémában minden create table utasítás mellett ott kell lennie a grant utasításoknak, az RLS bekapcsolásának és a szabályoknak.
4. Csak ott adjon jogosultságot, ahol az alkalmazásnak valóban szüksége van rá. Szerepkörönként külön, és mindig bekapcsolt RLS mellett. Azokat a táblákat, amelyeknek nem kell az API-n elérhetőnek lenniük, hagyja hozzáférés nélkül.
5. Próbálja ki az új működést egy másolaton. A Supabase közzétette azokat az utasításokat, amelyekkel a változás egy meglévő projektben már most bekapcsolható, és azokat is, amelyekkel visszaállítható. Először egy tesztprojekten futtassa őket, ne az éles alkalmazáson.
6. Frissítse az AI eszköz utasításait. A Supabase azt javasolja, hogy a jogosultsági lépést vegye fel a táblákat létrehozó eszköz rendszerpromptjába, vagy használja a Supabase agent skillt, amely ezt a lépést tartalmazza.

Így néz ki annak a példának a lényege, amelyet a Supabase egy új táblához ad. Utána következnek a konkrét sorokra vonatkozó RLS szabályok:

grant select on public.your_table to anon;
grant select, insert, update, delete on public.your_table to authenticated;
grant select, insert, update, delete on public.your_table to service_role;
alter table public.your_table enable row level security;

A 2026. május 30. után létrehozott projektek már az új működés szerint viselkednek, így ha GRANT utasítások nélküli régi migrációkat tölt be egy ilyen projektbe, például egy tesztmásolat létrehozásakor, a táblái nem lesznek elérhetők az API-n. Helyi fejlesztéshez a Supabase CLI ideiglenes auto_expose_new_tables beállítást vezetett be, amely a projekt egyik karbantartója szerint 2026. október 30-án megszűnik. Tartós megoldást csak a közvetlenül a migrációkban szereplő GRANT utasítások jelentenek.

Hol romlik el a gyakorlatban, és hogyan kezeljük

A legnagyobb kockázatot a határidő utáni első új funkció jelenti, amelyet senki sem tesztel valós adatokon.

Egy modellhelyzet így néz ki: egy cég AI builderrel épít belső eszközt vagy ügyfélportált, ez hónapokig működik, majd novemberben új résszel bővítteti. Az AI eszköz létrehoz egy táblát, az alkalmazás azonban nem látja, és az új rész üres marad vagy hibát jelez. Ha ugyanez az eszköz a hibát RLS nélküli tömeges jogosultságadással „javítja”, a probléma látható hibából csendes adatszivárgássá válik. A másik gyenge pont a régi migrációkból feltöltött tesztmásolat vagy új projekt, amely másként viselkedik, mint az éles alkalmazás.

Azoknál a cégeknél, amelyek külső fejlesztővel készíttették az alkalmazást, az a döntő kérdés, ki ad hozzá táblákat október 30. után, és tud-e erről a változásról. Ha ez egy módosítatlan utasításokkal futó AI eszköz vagy egy olyan fejlesztő, aki már nem gondozza a projektet, jobb most elvégezni az ellenőrzést. Ha az alkalmazást szlovákiai ügyfeleknek is nyújtja, olvassa el azt is, mit jelent a szoftverekre nézve az új szlovák termékfelelősségi törvény. A másolaton való tesztelés elve az éles üzem módosítása előtt ugyanaz, mint a WordPress frissítéseknél staginggel és rollbackkel.

Így csináljuk a Denvánál: az AI weboldalak javítását műszaki audittal kezdjük, és a megállapításokból még a munka megkezdése előtt fix árú tervet készítünk. Az első beavatkozás előtt mentést készítünk, és fejlesztői másolaton dolgozunk, hogy az élő alkalmazás tovább fusson, élesre pedig csak ellenőrzés után váltunk. A Supabase azon technológiák közé tartozik, amelyekkel az AI weboldalak javításakor rendszeresen dolgozunk.

Mikor oldja meg egyedül, és mikor velünk

Egyedül is megoldja, ha:

• az alkalmazás csak közvetlen kapcsolaton át kommunikál az adatbázissal, nem a Data API-n keresztül,
• a projektbe már nem kerülnek új táblák,
• ért a migrációkhoz, és a változást ki tudja próbálni egy tesztprojekten.

Érdemes minket bevonni, ha:

• a Security Advisor RLS nélküli táblákat jelez, vagy nem tudja, mely táblák nyilvánosak az API-n,
• az alkalmazás ügyfelek személyes adataival dolgozik, és egy jogosultsági hiba megnyitná őket,
• a kódot AI eszköz vagy egy korábbi fejlesztő írta, és senki sem tudja, hogyan épülnek fel a migrációk.

Összegzés: mit döntsön el október 30-ig

Ha az alkalmazás nem használja a Data API-t, vagy már nem kerül bele semmi új, elég tudomásul vennie a változást. Ha AI eszközzel tovább fejleszti, október végéig tegyen meg két dolgot: ellenőrizze, hogy a migrációk tartalmazzák-e a GRANT utasításokat az RLS-sel együtt, és vegye fel ezt a lépést az eszköz utasításai közé. Ha nem tudja, mely táblák nyilvánosak ma az API-n, ezzel kezdje, mert ez a Supabase oldali változástól függetlenül is biztonsági kérdés.

GYIK

Gyakori kérdések.

Leáll 2026. október 30-án a meglévő Supabase alkalmazásom?

Magától nem. A Supabase szerint a meglévő táblák megtartják az eddigi jogosultságaikat, és elérhetők maradnak a Data API-n. A változás az október 30. után létrehozott táblákat érinti, amelyeket GRANT utasítás nélkül az alkalmazás nem lát.

Honnan tudom, hogy az alkalmazásom használja-e a Supabase Data API-t?

Használja, ha a kódban megtalálja a supabase-js könyvtárat vagy a /rest/v1/, illetve /graphql/v1 címre irányuló hívásokat. Az az alkalmazás, amely csak connection stringen, ORM-en vagy saját szerveren keresztül kapcsolódik az adatbázishoz, nem érintett.

A változás a Lovable Cloudot vagy a Bolt adatbázist is érinti?

A Supabase bejelentése nem említi ezeket a kezelt backendeket, ezért ellenőrizze az adott eszköz dokumentációjában. Közvetlenül a Lovable-höz vagy a Bolthoz csatlakoztatott saját Supabase projektet érinti. A Lovable Cloud a Supabase nyílt forráskódú alapjára épül, de a Lovable kezeli.

Elég a permission denied hibát egy minden táblára kiterjedő GRANT utasítással javítani?

A hibát megszünteti, de megnyithatja az adatokat. Ha a táblán nincs bekapcsolva az RLS, minden jogosultsággal rendelkező szerepkör hozzáfér, a névtelen látogató is. Csak azokra a táblákra adjon jogosultságot, amelyekre az alkalmazásnak szüksége van, szerepkörönként, és mindig bekapcsolt RLS-sel és szabályokkal.

Bekapcsolhatom korábban az új működést, hogy kipróbáljam?

Igen. A Supabase közzétette azokat az SQL szerkesztőbe szánt utasításokat, amelyekkel a változás egy meglévő projektben már most bekapcsolható, és a visszaállító utasításokat is. Először egy tesztprojekten próbálja ki őket, majd vegye fel a GRANT utasításokat a migrációkba, és csak ezután futtassa őket az éles alkalmazáson.