Bezpečnost aplikací od AI: kontrolní seznam před zveřejněním

Aplikace, kterou vám AI postaví za odpoledne, často vypadá hotově. Funguje v náhledu, má tlačítka, někdy i přihlášení. Bezpečnost ale není vzhled. Jediný API klíč v kódu, tabulka bez omezení přístupu nebo formulář, který přijme cokoliv, stačí k tomu, aby se z užitečné hračky stala dražší starost.

Tento návod patří do série Tvoříme s AI a navazuje na specifikaci dřív než kód. Nemusíte být programátor. Potřebujete vědět, na co se zeptat a co si nechat ukázat, než aplikaci otevřete lidem. Pokud teprve začínáte, nejdřív si projděte úvod do vibe codingu a první webovou aplikaci.

Co budete potřebovat

• Hotovou nebo skoro hotovou aplikaci (chatbot, Lovable, Bolt, Cursor… – postup je stejný).
• Přístup k souborům projektu nebo k nastavení Secrets / Environment variables.
• Zhruba 45–90 minut na první průchod. U aplikace s přihlášením a databází počítejte spíš s horní hranicí.
• Druhý účet (nebo režim anonymního okna), abyste si vyzkoušeli, co vidí „cizí“ uživatel.

Kolik to stojí: samotná kontrola nic. Zaplacené kredity spotřebujete jen tehdy, když AI pomáhá hledat a opravit chyby. Bezpečnostní skeny v Lovable podle oficiální dokumentace při spuštění Quick i Deep scanu kredity neberou; kredity berou až konverzační „oprav to“ v chatu.

Proč AI nestačí „ujistit“, že je to bezpečné

AI umí napsat RLS politiku, schovat klíč do Secrets i navrhnout validaci formuláře. Stejně tak umí:

• nechat tajný klíč v souboru, který omylem pošlete na GitHub,
• zapnout databázi a zapomenout na přístupová pravidla,
• „opravit“ chybu tak, že otevře přístup všem,
• tvrdit, že je hotovo, i když jste si to nevyzkoušeli.

OWASP Top 10:2025 řadí na první místo Broken Access Control – tedy situace, kdy uživatel vidí nebo mění data, která mu nepřísluší. U aplikací z vibe codingu je to nejčastější skutečný problém: ne špionážní malware, ale „každý vidí všechny rezervace“.

Kontrolní seznam (vytiskněte si ho)

Projděte body shora dolů. U každého si napište ano / ne / netýká se. Až budete mít všude ano nebo netýká se, teprve zveřejňujte.

1. Žádné tajné údaje v kódu ani v chatu s AI (API klíče, hesla, tokeny).
2. Klíče jsou v Secrets / proměnných prostředí, ne v prohlížeči.
3. Na GitHubu (ani v historii) klíč není – a .env je v .gitignore.
4. Databáze má zapnutá přístupová pravidla (u Supabase RLS) a ověřené granty.
5. Cizí účet nevidí cizí data (vyzkoušeno v anonymním okně).
6. Formuláře a uploady mají limity (délka textu, typ souboru, velikost).
7. Závislosti nemají známé kritické díry, nebo víte, co s nimi uděláte.
8. Máte zálohu / verzi, ke které se vrátíte, když se něco rozbije.
9. Víte, jaké osobní údaje aplikace sbírá a proč (GDPR – alespoň základní přehled).
10. U plateb, zdravotních nebo citlivých dat máte lidskou kontrolu odborníka.

Krok 1: Najděte a odstraňte tajné údaje

Nejdřív požádejte AI o inventuru. Do chatu vložte:

Prohledej projekt a vypiš jen seznam míst, kde může být tajný údaj:
API klíče, hesla, tokeny, connection stringy, privátní klíče.

U každého uveď: soubor (nebo nastavení), proč to vypadá jako tajemství, a jestli je to v kódu frontendu (prohlížeč), backendu, nebo v Secrets.

Nikdy nevypisuj plnou hodnotu klíče. Stačí prvních 4 a posledních 4 znaky, zbytek nahraď ….
Navrhni konkrétní přesun do Secrets / proměnných prostředí. Zatím nic neměň, dokud neřeknu.

Pak:

• Klíč přesuňte do Secrets (Lovable) nebo do proměnných prostředí / serverové funkce.
• OpenAI v best practices pro API klíče výslovně říká: klíč nepatří do prohlížeče ani mobilní aplikace a nesmí se commitovat do repozitáře.
• Pokud klíč už unikl (do chatu, na GitHub, do snímku obrazovky), hned ho zneplatněte u poskytovatele a vytvořte nový. Starý považujte za kompromitovaný.
• Na GitHubu pomáhá push protection: push s detekovaným tajemstvím se zablokuje dřív, než se dostane do historie.

Nejčastější chyba: „Je to soukromý repozitář, tak to nevadí.“ Vadí. Stačí špatně nastavené oprávnění, forknutý export nebo pozdější zveřejnění.

Krok 2: Kdo smí vidět a měnit data

Pokud aplikace ukládá data (rezervace, kontakty, poznámky uživatelů), musí rozhodovat server nebo databáze, ne jen skryté tlačítko v rozhraní. OWASP u Broken Access Control varuje právě před kontrolou jen ve frontendu: útočník si stránku obejde přímo požadavkem.

U Supabase (a podobných backendů, které Lovable často používá):

1. Na každé tabulce v exposed schématu zapněte Row Level Security (RLS).
2. Odeberte zbytečné granty rolím anon / authenticated a vraťte jen to, co aplikace potřebuje.
3. Napište zvlášť pravidla pro čtení, zápis, úpravu a mazání.
4. Ověřte to testem: přihlaste se jako uživatel A a zkuste načíst data uživatele B.

Oficiální dokumentace Supabase to shrnuje ostře: tabulka v exposed schématu bez RLS je čitelná a zapisovatelná pro každou roli, která na ni má grant. Přidání politik samo o sobě granty neodvolá.

V Lovable otevřete Security view a spusťte Quick scan (běží i při publikaci). Dokumentace uvádí, že kontroluje mimo jiné tabulky bez RLS a pravidla, která pouštějí všechny. Deep scan jde dál do logiky oprávnění v kódu. Lovable zároveň upozorňuje, že skeny nenahrazují důkladnou bezpečnostní kontrolu u citlivých aplikací.

Prompt na kontrolu přístupů:

Zkontroluj přístup k datům v této aplikaci.

1. Které tabulky / kolekce existují a jaké osobní údaje drží?
2. Je u každé zapnuté omezení na úrovni záznamu (RLS nebo ekvivalent)? Pokud ne, navrhni minimální politiky: uživatel vidí a mění jen vlastní řádky.
3. Existuje cesta, jak bez přihlášení nebo s cizím účtem číst / mazat cizí data? Vypiš konkrétní URL nebo funkce.
4. Navrhni testovací scénář pro mě: co přesně mám udělat ve dvou účtech.

Zatím nic neměň. Piš česky a bez žargonu; odborný pojem vysvětli jednou větou.

Krok 3: Vstupy od lidí

Každé pole, kam uživatel píše, je vstup. AI často přidá hezký formulář a zapomene na limity.

Zkontrolujte:

• maximální délku textu,
• povolené typy a velikost nahrávaných souborů,
• že se vstup nelepí přímo do příkazu, SQL, e-mailu nebo promptu další AI bez kontroly,
• u veřejných endpointů rate limit (kolikrát za minutu jde akci spustit).

Prompt:

Projdi všechny formuláře, uploady a API endpointy v projektu.
U každého napiš: co uživatel smí poslat, jaká je maximální velikost / délka, co se stane při nesmyslném vstupu, a jestli může stejnou akci spouštět dokola bez omezení.
Navrhni nejmenší rozumné limity pro veřejnou verzi. Zatím nic neměň.

Krok 4: Závislosti a aktualizace

Aplikace skoro vždy táhne balíčky z npm. Lovable Quick scan umí audit závislostí; v jiných nástrojích se zeptejte AI nebo použijte npm audit (pokud máte projekt lokálně).

Neřešte každou varovnou hlášku panikou. Řešte kritické díry v balíčcích, které aplikace opravdu používá, a držte závislosti aktuální před větším zveřejněním.

Krok 5: Záloha a návrat

Než měníte oprávnění nebo „necháváte AI opravit bezpečnost“, uložte funkční verzi:

• commit na GitHub,
• export projektu,
• nebo alespoň zkopírované soubory a specifikaci.

Bezpečnostní „oprava“, která omylem otevře data všem, je horší než žádná oprava. Vraťte se k poslední dobré verzi a zkuste znovu po menších krocích – stejně jako v návodu ke specifikaci.

Krok 6: Test před zveřejněním (30 minut)

Až AI řekne, že je hotovo, nevěřte jí. Vyzkoušejte:

1. Otevřete aplikaci v anonymním okně (nejste přihlášení). Co ještě vidíte?
2. Vytvořte druhý účet. Vidí data prvního?
3. Zkuste změnit v adrese ID záznamu (např. /rezervace/1 → /rezervace/2). Zobrazí se cizí záznam?
4. Odešlete prázdný formulář a nesmyslně dlouhý text.
5. Podívejte se do nastavení Secrets: není tam klíč, který už nepotřebujete?

Když něco selže, zapište to a opravujte po jedné chybě. Po každé opravě test zopakujte.

Kdy přizvat programátora

Sami dál nechoďte, pokud aplikace:

• přijímá platby,
• drží zdravotní, školní nebo jiné citlivé osobní údaje ve větším rozsahu,
• je veřejná pro desítky nebo stovky lidí a má přihlášení,
• propojuje se s firemním e-mailem, účetnictvím nebo interní databází,
• má admin rozhraní „jen schované“ v URL.

Vibe coding je skvělý na prototyp a interní nástroje s nízkým rizikem. U ostrých dat platí stejné pravidlo jako u elektřiny: základní jistič zvládnete, rozvaděč nechte odborníkovi.

Nejčastější chyby

• „Vypadá to bezpečně.“ Bezpečnost se nepozná podle UI. Pozná se podle toho, co jde udělat s cizím účtem a s přímým požadavkem.
• Klíč v chatu s AI. Chat není trezor. Klíč zneplatněte.
• RLS „zapnuté“, ale politika pouští všechny. Quick scan v Lovable na to umí upozornit; stejně si to ověřte druhým účtem.
• Oprava deseti věcí najednou. Pak nevíte, co aplikaci rozbilo.
• Žádná specifikace toho, co aplikace sbírá. Bez seznamu údajů nevíte, co chránit. Vraťte se k šabloně specifikace.

Co tahle kontrola nezaručí

Ani dokonalý seznam neudělá z aplikace bankovní systém. Nové zranitelnosti v knihovnách přibývají, AI může při další úpravě bezpečnost znovu porušit a skenery mají slepá místa – Lovable to v dokumentaci přiznává. Cíl je jiný: nepustit ven nejbanálnější a nejdražší chyby, které u vibe codingu potkáváme pořád dokola.

Údaje o nástrojích a doporučeních jsme ověřili k 19. 10. 2026 v oficiální dokumentaci uvedené ve zdrojích.

Časté otázky

Stačí Security scan v Lovable? Na první záchyt ano, na klidné spaní u citlivých dat ne. Spusťte Quick i Deep scan, opravte kritické nálezy a stejně si vyzkoušejte cizí účet.

Můžu dát API klíč do frontendu, když ho „schovám“ v kódu? Ne. Cokoliv v prohlížeči jde přečíst. Klíč patří na server (nebo do oficiálního connectoru / Secrets s voláním mimo prohlížeč).

Aplikace běží jen u mě a u tří kolegů. Musím to řešit? Ano, aspoň body 1–3 a 5. Interní nástroj s uniklým klíčem nebo otevřenou tabulkou dokáže napáchat stejnou škodu jako veřejný web.

Shrnutí

• Před zveřejněním aplikace od AI projděte kontrolní seznam: klíče, přístup k datům, vstupy, závislosti, záloha, test cizím účtem.
• Broken Access Control (každý vidí vše) je u těchto aplikací častější problém než „hackeři z filmu“.
• AI ať pomáhá hledat a navrhovat; rozhodnutí a testy jsou vaše.
• U plateb a citlivých dat přizvěte člověka, který kódu rozumí.
• Návod navazuje na specifikaci a úvod série. Jak ukládat verze a vrátit se k funkční aplikaci, ukazuje návod Verze, Git a GitHub bez strachu. Další díly série se zaměří na data a přihlašování i na práci s AI agenty v editoru.