# Kdo se dostane do vaší databáze. Zkuste si to sami

https://www.magnapro.eu/blog/kdo-se-dostane-do-vasi-databaze

*Publikováno: 2026-09-22 · Rubrika: Kyberbezpečnost*

Aplikace ukazuje každému jen jeho data. Otázka je, kdo o tom rozhoduje: aplikace, nebo databáze. Tři testy, které zvládne kdokoli, kdo umí otevřít prohlížeč.

V databázi máte tabulku objednávek. Každý řádek patří nějakému zákazníkovi. Aplikace ukazuje přihlášenému člověku jen jeho objednávky, takže to vypadá v pořádku.

Otázka zní, kdo o tom rozhoduje. Jestli aplikace, nebo databáze.

Rozdíl je zásadní a je to nejčastější díra v aplikacích postavených pomocí AI.

## Filtr v aplikaci není zámek

Když kód řekne „vyber objednávky, kde se zákazník rovná přihlášenému uživateli", je to filtr. Databáze poslušně vrátí, co se po ní chce. Kdyby se jí někdo zeptal jinak, vrátí i jiné řádky, protože jí nikdo neřekl, že nemá.

Filtr běží v prohlížeči. Prohlížeč je počítač návštěvníka. Na svém počítači si každý může změnit, co chce.

Zámek se nastavuje v databázi. Říká: tenhle uživatel smí vidět jen řádky, kde je v poli **owner** jeho identifikátor. Když se zeptá na cokoli jiného, dostane prázdno. A je to jedno, jak se zeptá a odkud.

U Supabase, což je databáze, kterou používá většina těchto nástrojů, se tomu říká Row Level Security. Ve výchozím stavu je vypnutá. Pokud ji nikdo nezapne a nenapíše k ní pravidla, tabulka je otevřená.

## Co to znamená prakticky

Aplikace posílá dotazy do databáze přes webové rozhraní. To rozhraní je veřejné, jinak by z prohlížeče nešlo použít. Kdokoli tedy může poslat stejný dotaz jako vaše aplikace, jen si ho napíše po svém.

Ve výzkumu, který v březnu 2025 udělal Matt Palmer, bylo **303 takových otevřených koncových bodů ve více než 170 aplikacích** postavených v Lovable. Zranitelnost dostala označení CVE-2025-48757.

Přístupné byly e-maily, telefonní čísla, údaje o platbách a předplatném a API klíče. Nešlo o žádný sofistikovaný útok. Stačilo se zeptat.

Lovable na to vydalo skener, který hlásí, jestli na tabulce nějaké pravidlo je. Nekontroluje, co to pravidlo dělá. Pravidlo, které pustí všechny, skenerem projde.

## Druhá cesta dovnitř: přihlášení, které nic nehlídá

Aplikace může mít databázi zamčenou a přesto být otevřená. Stačí, když se do ní dá vytvořit účet, který tam být nemá.

V červenci 2025 popsala bezpečnostní firma Wiz chybu na platformě Base44, kterou vlastní Wix. Dva koncové body pro registraci a ověření kódu z e-mailu nevyžadovaly žádné přihlášení. Útočníkovi stačilo znát identifikátor aplikace, a ten je běžně vidět v adrese a v souboru **manifest.json**.

Postup byl tenhle. Zaregistrovat se, počkat na kód v e-mailu, potvrdit ho, být uvnitř. I v aplikaci, která byla nastavená jen pro firemní přihlášení přes jednotný účet.

Wiz to nahlásil 9. července, oprava byla ověřená 10. července a potvrzená 13. července. Reakce byla rychlá. Ale do té doby ta chyba fungovala na všech aplikacích postavených na té platformě.

## Vyzkoušejte si to na vlastní aplikaci

Tohle zvládne kdokoli, kdo umí otevřít prohlížeč.

**Test první: co vidí nepřihlášený člověk**

Otevřete anonymní okno. Vložte do něj adresu stránky, která je jen pro přihlášené. Pokud se stránka načte a data se objeví, je to špatně. Pokud se načte a data se neobjeví, otevřete F12 a kartu Síť. Podívejte se, jestli přišla prázdná odpověď, nebo jestli data přišla a jen je aplikace neukázala. Druhá varianta je taky špatně.

**Test druhý: co vidí jiný přihlášený člověk**

Vytvořte si druhý účet. Přihlaste se pod ním. V adrese najděte číslo nebo identifikátor, který patří vašemu prvnímu účtu, a přepište ho. Když se objeví cizí data, zámek chybí.

Tomuhle se říká nezabezpečený přímý odkaz na objekt a je to jedna z nejčastějších chyb v aplikacích, které psala AI. Útočník k tomu nepotřebuje nic než změnit jedno číslo v adrese.

**Test třetí: registrace tam, kde být nemá**

Jestli je aplikace jen pro vás a pro kolegy, zkuste se do ní zaregistrovat z anonymního okna s cizím e-mailem. Mělo by to skončit odmítnutím.

## Když něco najdete

Klidně. Není to důvod aplikaci zahodit.

Pořadí prací bývá skoro vždycky stejné. Nejdřív se zapne ochrana na úrovni řádků u všech tabulek, včetně těch, na které se zapomnělo. Pak se ke každé tabulce napíše pravidlo, které odpovídá tomu, jak se data skutečně používají. Nakonec se to otestuje druhým účtem, protože pravidlo, které nikdo nevyzkoušel, je jen dobrý úmysl.

Zvlášť se řeší tabulky, ke kterým aplikace přistupuje přes servisní klíč. Ty ochrana na úrovni řádků neochrání, protože servisní klíč ji z principu obchází. Tam se musí přesunout logika na server.

Nepřepisuje se přitom to, co funguje. Aplikace, která má správně vymyšlené procesy a běží na reálných datech, má hodnotu. Opravuje se vrstva pod ní.

Přístupová práva a to, kdo kam vidí, patří do pravidelné [správy firemního IT](https://www.magnapro.eu/sluzby/outsourcing).

Série o aplikacích postavených s pomocí AI, díl 2 z 5. Předchozí díl: [Kam vaše aplikace ukládá hesla, když jste ji nepsali vy](https://www.magnapro.eu/blog/kam-aplikace-uklada-hesla-kdyz-jste-ji-nepsali-vy). Další díl: [Co se stane, až to spadne. A ono to spadne](https://www.magnapro.eu/blog/co-se-stane-az-aplikace-spadne).

---

Zdroj: MAGNAPRO s.r.o., https://www.magnapro.eu/blog/kdo-se-dostane-do-vasi-databaze