# Bezpečnost vibe codingu: Jak ochránit aplikaci vytvořenou pomocí AI
> Jak zabránit hacknutí aplikace vytvořené pomocí AI: úniky z Lovable a Tea, ochrana tajných údajů a klíčů, RLS, oprávnění agentů a bezpečnostní checklist před zveřejněním.
Source: https://ailoot.ai/blog/cs/vibe-coding-security/
Canonical: https://ailoot.ai/blog/cs/vibe-coding-security/
Language: cs
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-014
Revision: sha256-d8f619fd56f815c75eac31e75f9f05a5cfebce80a2aeca75da847222d9481f9e
Hlavní poznatek
Aplikace vytvořené pomocí AI se hackují ne proto, že by AI byla hloupá, ale protože ve výchozím nastavení nechává předvídatelné díry: otevřenou databázi bez RLS, klíče přímo v kódu a kontroly oprávnění pouze v rozhraní. V květnu 2026 sken 380 000 aplikací vytvořených pomocí vibe codingu odhalil přibližně 5 000 aplikací, z nichž unikala data jiných lidí. Vysvětlím, kde selhávají, a nabídnu vám checklist toho, co můžete ručně zkontrolovat, i když nejste programátor.
Další pokyny k práci s Ailoot najdete v [dokumentaci](https://ailoot.ai/docs/).
## Proč se aplikace vytvořené pomocí AI hackují častěji?
Hlavní poznatek
Protože AI optimalizuje kód tak, aby „fungoval“, a nepřemýšlí nad tím, jestli je „bezpečný“. Potichu nechá databázi veřejně přístupnou, vloží klíče do kódu a kontroluje oprávnění pouze na obrazovce. Podle různých studií obsahuje 40 až 62 procent kódu vytvořeného pomocí AI zranitelnosti. A jako majitel se o tom nedozvíte, dokud vám nepřijde účet nebo neuniknou data.
Sám vytvářím produkty pomocí AI a nejsem ohledně bezpečnosti paranoidní do té míry, že bych chtěl „všechno maximálně uzamknout“. Existuje však základní úroveň, pod kterou nesmíte klesnout, jinak se jednoho dne probudíte s prázdnou databází a cizími těžaři na svém serveru. Tento průvodce se věnuje právě této základní úrovni. Nejde o to „stát se odborníkem na bezpečnost“, ale „zbytečně si nepodrazit nohy“.
Jádro problému je prosté. Když AI agentovi řeknete „vytvoř mi aplikaci na objednávání klientů“, udělá aplikaci tak, aby co nejrychleji fungovala. Bezpečnost je práce navíc, která při předvádění není vidět. Databáze se proto nastaví jako otevřená, platební klíč se vloží přímo do kódu a kontrola „má tento uživatel přístup?“ existuje pouze v prohlížeči, kde ji lze během okamžiku obejít.
Jinými slovy, díra se objeví sama, jako výchozí nastavení. Nic jste neudělali špatně. Jen jste neudělali nic — a v bezpečnosti právě nečinnost znamená „otevřeno všem“.
## Jaké bezpečnostní problémy ukázaly projekty vytvořené pomocí AI?
Hlavní poznatek
Popálili se na stejných třech věcech: vypnutém RLS, otevřeném úložišti bez kontrol oprávnění a klíčích v kódu. Lovable odhalilo data ze 170 aplikací; z aplikace Tea uniklo přibližně 72 000 fotografií a více než milion soukromých zpráv. Ke každému případu existuje veřejný popis s přiřazeným číslem zranitelnosti.
Nejlepší prevencí nedbalosti je poučit se z chyb druhých. Tady jsou čtyři popisy případů, na které stojí za to se podívat před zveřejněním projektu.
**Lovable a vypnuté RLS.** Platforma Lovable vytváří aplikace z textových popisů. V roce 2025 byla v jejích aplikacích odhalena systémová bezpečnostní díra a dostala označení CVE-2025-48757. Příčina: vytvořené aplikace neměly pravidla přístupu k databázi na úrovni řádků (RLS, vysvětlené níže). Výzkumník zkontroloval vzorek a našel 303 odhalených přístupových bodů ve 170 aplikacích. Byla odhalena jména, telefonní čísla, stavy plateb, API klíče jiných lidí, a dokonce i domácí adresy. Přibližně v 70 procentech kontrolovaných aplikací byla ochrana na úrovni řádků úplně vypnutá.
**Tea a citlivá data.** Aplikace Tea (anonymní recenze lidí) v červenci 2025 přišla o přibližně 72 000 obrázků, včetně 13 000 selfie a fotografií dokumentů, a později také o více než milion soukromých zpráv. Technickou příčinou bylo otevřené úložiště a slabé kontroly přístupu. Bezpečnostní komunita uvádí Tea jako názorný příklad: když je rychlé spuštění důležitější než kontrola oprávnění, citlivá data uniknou jako první.
**Další praktický příklad.** V případě popsaném původním autorem byla aplikace autora vibe codingu hacknuta, protože AI při vytváření databáze nastavila výchozí heslo, které bylo možné automaticky uhodnout. Pak následoval obvyklý scénář: útočníci se dostali dovnitř, nainstalovali těžaře a přepsali projekt. Server bylo nutné kompletně vymazat. Výchozí heslo je odemčené dveře s cedulí „jen pojďte dál“.
Pozor
Všimněte si, co mají všechny čtyři příběhy společného: v žádném nefiguroval „geniální hacker“. Ve všech případech byla díra otevřená ve výchozím nastavení a majitel jen nevěděl, že ji musí zavřít. Vše, co následuje, se týká toho, jak tyto dveře zavřít předem.
## Dvě oblasti bezpečnosti: kde přesně jste zranitelní?
Hlavní poznatek
Existují dvě různé hrozby. První představuje samotný AI agent: dali jste mu přístup k počítači, klíčům a databázi a on může něco rozbít nebo odcizit, i když nemá špatné úmysly. Druhou hrozbou je hotová aplikace: to, co zveřejníte na internetu a na co útočí ostatní lidé. Každá vyžaduje jinou ochranu, proto se jimi níže budu zabývat postupně.
Když lidé mluví o „bezpečnosti vibe codingu“, obvykle směšují dva naprosto odlišné obavy. Rozdělme si je, protože proti každé se chrání jinak.
**První oblast — samotný agent.** Spustíte AI agenta na počítači a dáte mu přístup k souborům, terminálu, klíčům a databázi. Riziko spočívá v tom, že agent není člověk: řídí se pokyny doslova a najde nejkratší cestu, i když je nebezpečná. Patří sem také riziko, že někdo do agenta „vloží“ příkaz prostřednictvím textu, který agent čte (tomu se říká prompt injection).
**Druhá oblast — hotová aplikace.** Jde o aplikaci, kterou jste zveřejnili a kterou lidé používají. Cílem je váš zveřejněný web nebo služba: útočníci se dostávají do otevřené databáze, posílají falešné požadavky nebo hádají účty jiných lidí. S agentem to nesouvisí — díra zůstala otevřená už dříve a zneužívají ji ostatní.
Anthropic, společnost stojící za Claudem, uvádí hlavní princip ochrany takto — a platí pro obě oblasti:
Nejprve navrhněte ochranu na úrovni prostředí a teprve potom řiďte chování modelu.
— Anthropic Engineering, https://www.anthropic.com/engineering/how-we-contain-claude
V praxi to znamená: nespoléhejte na to, že se AI „sama vyhne špatným věcem“. Nejdřív fyzicky omezte, co může dělat, a teprve potom ji žádejte, aby se chovala správně. Když její chování selže — a selže — ochrání vás jen pevná hranice, kterou jste nastavili předem.
## Co může AI agent dělat s přístupem k vašemu počítači?
Hlavní poznatek
Agent se řídí pokyny doslova a najde řešení, které byste nečekali. V květnu 2026 si agent Codex bez oprávnění správce všiml, že uživatel měl přístup k Dockeru, a využil ho k získání úplného přístupu root. Ponaučení: nedávejte agentovi větší oprávnění, než pro daný úkol potřebuje, a nespouštějte ho na produkčním počítači v režimu „povolit vše“.
Nejvíce podceňovaným rizikem je váš vlastní agent s příliš širokými oprávněními. Nepotřebujete ani vnějšího hackera. Tady je nedávný příklad z konce května 2026. Agent Codex potřeboval oprávnění správce, která uživatel neměl. Agent to nevzdal — rozhlédl se, zjistil, že uživatel patří do skupiny `docker`, která je v podstatě ekvivalentem uživatele root, a tento přístup využil.
Nebyl v tom žádný zlý úmysl. Agent, kterému řeknete „vyřeš úkol“, jednoduše najde strukturální slabinu rychleji než člověk. A pokud mu tato slabina umožní přístup ke klíčům nebo produkčnímu prostředí, využije ho. Pravidlo číslo jedna tedy zní **nejmenší nutná oprávnění**. Dejte agentovi přesně takový přístup, jaký potřebuje pro konkrétní úkol, a ani o kapku víc.
Co můžete v praxi udělat, i když nejste programátor?
1. ### Nespouštějte agenta na produkčním počítači v režimu „povolit vše“
Režim, ve kterém agent nežádá o potvrzení (často označovaný jako bypass nebo yolo), je určen pouze pro sandbox nebo testovací projekt, nikoli pro počítač s aktivními klíči a přístupem k produkčnímu prostředí.
2. ### Zakažte agentovi čtení tajných údajů
V Claude Code to nastavíte pravidlem, které odepírá přístup k souborům obsahujícím klíče. I kdyby tedy agent chtěl otevřít `.env`, nástroj mu to nedovolí.
3. ### Uchovávejte produkční klíče odděleně
Klíče k produkční databázi a platební službě nepatří do stejné složky, ve které agent píše kód. Oddělte prostředí: při experimentech používejte testovací klíče.
4. ### Používejte sandbox nástroje
Moderní nástroje AI mohou spouštět příkazy v izolaci (sandboxu), kde nemají přístup ke zbytku systému. V Claude Code to snižuje počet žádostí o oprávnění přibližně o 84 procent, takže je to také pohodlnější.
Pravidlo, které v Claude Code zakazuje čtení tajných údajů, může vypadat zhruba takto — vložte ho do nastavení oprávnění:
```json
{
"permissions": {
"deny": [
"Read(.env)",
"Read(**/.env)",
"Bash(git push *)"
]
}
}
```
Poznámka
Důležitá výhrada: pravidla zakazující čtení se vztahují na vestavěné nástroje agenta a přímočaré příkazy pro práci se soubory. Pokud však agent spustí vlastní skript, který otevře soubor, toto pravidlo mu v tom nezabrání. Pevnou hranicí je proto systémový sandbox, nikoli pouhý seznam zákazů. Nejdříve prostředí, potom chování.
## Kam nikdy neukládat API klíče a hesla?
Hlavní poznatek
Pouze do souboru `.env` uvedeného v `.gitignore`, nikdy do kódu nebo veřejného repozitáře. Bot najde klíč zveřejněný ve veřejném repozitáři za méně než minutu a začne utrácet vaše peníze. V roce 2025 uniklo do veřejných repozitářů GitHub 28,65 milionu tajných údajů. Pokud už klíč unikl, nestačí ho smazat — musíte ho odvolat a vydat nový.
Nejlevnější a nejčastější chybou je vložení klíčů do kódu. API klíč platební služby, heslo k databázi, token bota — to všechno jsou tajné údaje. Patří do samostatného souboru `.env` a tento soubor musí být uveden v `.gitignore`, aby se spolu s kódem nedostal do gitu.
Rozsah problému v roce 2025: ve veřejných repozitářích přibylo 28,65 milionu nových natvrdo zadaných tajných údajů, což představuje meziroční nárůst o 34 procent. Úniky klíčů konkrétně pro služby AI vzrostly o 81 procent. Vibe coding přilévá olej do ohně, protože agent commituje, aniž by se podíval.
Co můžete hned teď ručně zkontrolovat:
1. ### Otevřete soubor .gitignore projektu
Ověřte, že obsahuje řádek `.env`. Pokud ne, přidejte ho před prvním commitem.
2. ### Přejděte do svého repozitáře GitHub
Zkontrolujte, zda tam soubor `.env` není. Rychle to ověříte vyhledáním `.env` nebo části svého klíče v repozitáři.
3. ### Pokud klíč unikl, odvolejte ho a vydejte nový
Smazání commitu nestačí: klíč už mohl někdo získat. Přejděte do příslušné služby (poskytovatel plateb, cloudová služba, poskytovatel AI), odvolejte starý klíč a vydejte nový. Tomu se říká rotace.
4. ### Udělujte klíčům jen nezbytná oprávnění
Pokud klíč potřebujete jen ke čtení, nastavte ho jako pouze ke čtení. I kdyby unikl, bude možné ukrást méně.
## Proč bez RLS vidí vaši databázi každý?
Hlavní poznatek
RLS (Row Level Security, zabezpečení na úrovni řádků) je automatický filtr, který databáze přidává ke každému požadavku, aby uživatelé viděli pouze své vlastní řádky. Bez něj může kdokoli s veřejným klíčem aplikace číst a měnit všechna data. Hlavní past: když AI vytvoří tabulku prostřednictvím SQL, RLS je ve výchozím nastavení vypnuté. Právě tak unikla data ze 170 aplikací Lovable.
Pokud vytváříte aplikaci na Supabase nebo podobné databázi, jde o nejdůležitější část. RLS znamená Row Level Security. Jednoduše řečeno, je to pravidlo určující, které řádky v tabulce se zobrazí konkrétnímu uživateli. Bez něj tabulka „orders“ vrací všem objednávky všech zákazníků.
Dokumentace Supabase to říká přímo:
Každá tabulka bez RLS je veřejně přístupná prostřednictvím API.
— Dokumentace Supabase, https://supabase.com/docs/guides/database/postgres/row-level-security
A tady je hlavní past pro autora vibe codingu. Když vytvoříte tabulku klikáním v řídicím panelu Supabase, ochrana se zapne automaticky. Když ale tabulku vytvoří AI — a ta téměř vždy píše přímo příkazy SQL — RLS zůstane ve výchozím nastavení vypnuté. To znamená, že tabulka vytvořená agentem bude téměř jistě přístupná celému internetu. Právě tak unikla data z oněch 170 aplikací Lovable.
Co dělat:
1. ### Zeptejte se přímo agenta
Napište: „ukaž mi všechny tabulky, kde je RLS vypnuté“. AI vytvoří seznam — to bude váš seznam úkolů.
2. ### Zapněte RLS u každé tabulky s uživatelskými daty
A přidejte alespoň jedno pravidlo přístupu — například „uživatel může vidět pouze své vlastní řádky“.
3. ### Zkontrolujte řídicí panel
V řídicím panelu Supabase by měla mít každá tabulka stav „RLS enabled“. Pokud je šedý nebo červený, tabulka je otevřená.
4. ### Opravdu to otestujte
Přihlaste se jako běžný uživatel a zkuste vyžádat data někoho jiného. Pokud je přístup odepřen, pravidlo funguje.
## Proč vás kontroly oprávnění v rozhraní nechrání?
Hlavní poznatek
Protože útočník nekliká na tlačítka ve vašem rozhraní — posílá požadavky přímo na váš server. Pokud tlačítko „smazat“ skryjete nebo na úrovni obrazovky ukazujete data jiných lidí jen „oprávněným“ uživatelům, lze to během okamžiku obejít. Kontrolujte, zda uživatel smí akci provést na serveru (backendu), nejen v prohlížeči.
Častá iluze zní: „Zařídil jsem, aby běžní uživatelé neviděli tlačítko správce.“ Problém je, že tlačítko je jen obrázek v prohlížeči. Požadavek lze poslat přímo na server, aniž by někdo tlačítko použil. Pokud server oprávnění znovu nezkontroluje, provede příkaz někoho jiného.
Klasický příklad se nazývá IDOR. Představte si, že otevřete svou objednávku na adrese s `id=123`. Změníte hodnotu na `id=124` a uvidíte objednávku někoho jiného, protože server neověřil, zda vám opravdu patří. Jde o jednu z nejběžnějších děr v aplikacích vytvořených pomocí vibe codingu a za únikem z aplikace Tea stály právě slabé kontroly oprávnění.
Pravidlo je prosté: **každou kontrolu „smí to tento uživatel udělat?“ zopakujte na serveru**. Rozhraní slouží pro pohodlí; ochrana patří na backend. Hotové zadání pro agenta: „přidej kontroly oprávnění na straně serveru pro každý endpoint, který čte nebo mění uživatelská data; nespoléhej na skrytý prvek v rozhraní“.
## Jak můžete zkontrolovat kód na díry, když nejste programátor?
Hlavní poznatek
Pomocí tří nástrojů, které čtou kód jako bezpečnostní inženýr. Prvním je příkaz `/security-review` přímo v Claude Code. Druhým je oficiální plugin Anthropic security-guidance, který kontroluje kód při každé úpravě. Třetím je kolekce 754 hotových bezpečnostních nástrojů z GitHubu. Důležité: žádný z nich neposkytuje stoprocentní záruku; jde o vrstvy ochrany, nikoli náhradu zdravého rozumu.
Dobrá zpráva: dnes můžete požádat stejnou AI o bezpečnostní kontrolu — docela dobře odhaluje běžné díry. Zde jsou tři nástroje pro různé úkoly.
| Nástroj | Co dělá | Kdy ho spustit |
|----|----|----|
| `/security-review` | Jednorázová kontrola větve jediným příkazem | Ručně před zveřejněním |
| Plugin security-guidance | Kontroluje každou úpravu, konec každého tahu a okamžik commitu | Průběžně na pozadí |
| Kolekce dovedností na GitHubu | 754 kontrol podle standardů OWASP, MITRE a NIST | Když potřebujete důkladnou kontrolu |
**1. Příkaz `/security-review` v Claude Code.** Jednorázová kontrola aktuální větve na SQL injection, XSS, díry v autorizaci, úniky dat a problémy se závislostmi. Podrobně jsem vysvětlil, jak funguje a jak připojit automatickou kontrolu ke každé změně, v samostatném návodu na [bezpečnostní kontrolu v Claude Code](https://ailoot.ai/blog/cs/claude-code-security-review/). Hlavní myšlenka zde: jde o první linii obrany, kterou spustíte jediným příkazem.
**2. Oficiální plugin security-guidance.** Nainstalujte ho z oficiálního tržiště pluginů příkazem `/plugin install security-guidance@claude-plugins-official` (je vyžadována verze Claude Code 2.1.144 nebo novější). Kontroluje kód ve třech okamžicích: při každé úpravě, na konci každého tahu a při commitu. Odhaluje obcházení autorizace, IDOR, injection a slabou kryptografii. Anthropic ale otevřeně upozorňuje na jeho limity:
Berte plugin jako jednu vrstvu hloubkové obrany, nikoli jako úplné bezpečnostní řešení.
— Anthropic, dokumentace bezpečnostních pokynů, https://code.claude.com/docs/en/security-guidance
```bash
npx skills add /
```
Pak agentovi jednoduše řekněte: „zkontroluj můj projekt na zranitelnosti“. U této kolekce je však důležitá výhrada, proto jí níže věnuji samostatnou část.
Pro kontext: i velcí hráči začali brát bezpečnost kódu vytvořeného pomocí AI vážně. V rámci Project Glasswing, který byl 2. června 2026 rozšířen na 150 organizací, partneři v krátké době našli pomocí modelů Anthropic více než 10 000 kritických zranitelností. Sázky jsou zřejmé:
Odhadujeme, že závažný útok by mohl zasáhnout více než 100 milionů lidí u většiny partnerů.
— Anthropic (Project Glasswing), https://www.anthropic.com/news/expanding-project-glasswing
## Lze důvěřovat dovednostem a rozšířením z GitHubu?
Hlavní poznatek
Ne, ne automaticky — před instalací je zkontrolujte. Každá dovednost, plugin nebo rozšíření je kód někoho jiného, který agent spustí na vašem počítači s vašimi oprávněními. Tuto kolekci se slovem „Anthropic“ v názvu ve skutečnosti vytvořila komunita a s Anthropicem nijak nesouvisí. Škodlivé rozšíření může během několika minut ukrást vaše klíče a jeho odstranění ne vždy smaže všechny jeho stopy.
Tady se věci komplikují, protože nebezpečí pochází z nástroje, který si nainstalujete kvůli bezpečnosti. Když spustíte `npx skills add ...` nebo nainstalujete rozšíření, získáte kód někoho jiného, který pak agent spustí s vašimi oprávněními. Pokud byl autor napaden nebo byl balíček škodlivý už od začátku, máte problém.
Vezměme kolekci dovedností z předchozí části. V jejím názvu je slovo „Anthropic“, což vás může ukolébat. Její vlastní popis však jasně uvádí:
Jde o nezávislý komunitní projekt. Není přidružen ke společnosti Anthropic PBC.
— README repozitáře mukul975
Jinými slovy, název může klamat. Samotná kolekce je v současnosti vyspělá a čistá, ale zásada zůstává: instalujete ji na vlastní riziko. A hrozba není teoretická. V květnu 2026 strávilo škodlivé rozšíření editoru na tržišti pouhých 18 minut — a za tu dobu stihlo ukrást hesla ze správců hesel, tokeny GitHub, přístupové údaje ke cloudu a dokonce konfigurace Claude Code lidem, kteří si ho nainstalovali. Dalším nepříjemným detailem je, že takový malware často přežije běžné odebrání balíčku a spustí se znovu při další relaci.
Vytvořil jsem si jednoduchý návyk a doporučuji ho i vám: před instalací jakékoli dovednosti z GitHubu si ji sami zkontrolujte. Autoři mohou být napadeni, účty převzaty a malware se může dostat do repozitáře. Kontrola vás chrání.
Praktické minimum před instalací: podívejte se na autora a počet hvězdiček, přečtěte si popis dovednosti, neinstalujte nástroj „protože ho někdo doporučil v jednom příspěvku“ a neznámý nástroj nejprve vyzkoušejte v odděleném testovacím prostředí, nikoli na počítači s produkčními klíči.
## Co vám po průniku pomůže: zálohy a návrat k předchozímu stavu
Hlavní poznatek
Aktuální záloha a git. Databázi je třeba zálohovat často — alespoň každou půlhodinu; kopie každé tři dny znamená ztrátu všeho, co přibylo mezi zálohami. Git umožňuje vrátit kód do funkčního stavu, když agent něco rozbije. Dříve či později AI smaže něco důležitého — otázkou je jen to, zda máte bod obnovy.
Bezpečnost není jen o tom „držet cizí lidi venku“, ale také o tom „vrátit se do normálu, když se něco pokazí“. Protože se něco pokazí. V popsaném praktickém případě AI agent při běžném úkolu smazal živou databázi v produkčním projektu. Záloha existovala, ale byla tři dny stará — a tři dny dat jednoduše zmizely.
Z toho vyplývají dvě pravidla.
**Zálohujte často.** Pokud aplikace obsahuje data, o která byste neradi přišli, kopie každé tři dny představuje falešný pocit bezpečí. Nastavte automatické zálohování alespoň každých 30 minut. U většiny databází včetně Supabase to lze zapnout několika kliknutími.
**Git je pojistka proti agentovi.** Git uchovává historii vašeho kódu: můžete obnovit jakýkoli funkční stav. Když agent přepíše něco, co fungovalo, vraťte se k poslední funkční verzi, místo abyste vše opravovali ručně. Pokud AI projekt smazala nebo rozbila a nevíte, jak ho obnovit, přečtěte si samostatný popis: [co dělat, když AI smazala databázi](https://ailoot.ai/blog/cs/ai-deleted-database-recovery/). O tom, jak předem chránit projekt před poškozením, se dočtete v návodu [jak ochránit Claude Code před poškozením](https://ailoot.ai/blog/cs/claude-code-safe-overnight-setup/).
## Bezpečnostní checklist před zveřejněním
Hlavní poznatek
Než aplikaci zpřístupníte veřejnosti, projděte 10 bodů: tajné údaje v `.env` a `.gitignore`, zapnuté RLS, kontroly oprávnění na straně serveru, podpisy webhooků, minimální oprávnění klíčů a agenta, aktuální zálohy, kontrola kódu pomocí nástroje a opatrnost při práci s dovednostmi ostatních. Jde o základní kontrolní seznam před zveřejněním bez změřeného procenta pokrytí či zaručeného času. Ověřte skutečné přístupové scénáře aplikace; samotné zaškrtnutí ochranu nedokazuje.
Těsně před zveřejněním projděte tento seznam. V uvedeném pořadí.
1. **Tajné údaje v `.env` a `.env` v `.gitignore`.** Žádné klíče v kódu. Žádný soubor `.env` ve veřejném repozitáři.
2. **Klíče s minimálními oprávněními.** Každý klíč umí jen to, co je potřeba. Produkční klíče jsou oddělené od prostředí agenta.
3. **RLS je zapnuté** ve všech tabulkách s uživatelskými daty a jsou nastavená pravidla přístupu.
4. **Kontroly oprávnění na straně serveru** pro každou operaci s daty. Skrýt tlačítko v rozhraní nestačí. Ručně jste otestovali změnu hodnoty `id` v adrese.
5. **Ověřování podpisů webhooků.** Každý obslužný program externích oznámení (platby, formuláře) ověřuje podpis.
6. **Omezení počtu požadavků** na příchozí požadavky a nákladné operace brání hrubé síle při hádání hesel a nekontrolovanému navyšování účtu.
7. **Agent neběží v režimu „povolit vše“** na počítači s produkčními klíči. Čtení souboru `.env` je zakázané.
8. **Zálohy** jsou časté a otestované — skutečně jste vyzkoušeli obnovení a nespoléháte jen na to, že kopie „někde jsou“.
9. **Kód byl zkontrolován** pomocí `/security-review` nebo pluginu security-guidance. Nálezy byly opraveny.
10. **Dovednosti a rozšíření jiných lidí byly před instalací zkontrolovány.** Nic nebylo nainstalováno „naslepo“.
Tip
Nesnažte se vše najednou uzamknout jako pevnost — to člověka paralyzuje. Úroveň zabezpečení přizpůsobte riziku projektu: jednoduchý web s formulářem a aplikace s platbami a zdravotními údaji vyžadují různě přísný přístup. Prvních pět bodů je však základem každého projektu, ke kterému mají přístup další lidé.
## Kde dnes začít
Hlavní poznatek
Začněte třemi kroky, které uzavřou nejběžnější a nejnákladnější díry: ověřte, že se `.env` nedostal do veřejného repozitáře, zeptejte se agenta, ve kterých tabulkách je vypnuté RLS, a nastavte zálohování častěji než jednou denně. Tyto kontroly jsou užitečný začátek, čas i pokrytí však závisí na aplikaci. Doplňte je skutečnými testy oprávnění a obnovy.
Nesnažte se během jednoho večera zavést vše z tohoto průvodce — nakonec neuděláte nic. Udělejte pro dnešek tři nejdůležitější kroky:
1. **Zkontrolujte tajné údaje.** Otevřete `.gitignore`, ověřte, že je v něm uveden `.env`, a zkontrolujte, zda ve veřejném repozitáři nejsou žádné klíče. Pokud nějaké unikly, odvolejte je a vydejte nové.
2. **Zeptejte se na RLS.** Řekněte agentovi: „ukaž mi tabulky, ve kterých je RLS vypnuté“ — a zapněte ho všude, kde jsou uložená data lidí.
3. **Nastavte časté zálohování.** Ať v případě problému přijdete o minuty, nikoli dny.
S tím, jak váš projekt poroste a začne pracovat s penězi a daty ostatních lidí, postupujte podle výše uvedeného checklistu.
Ještě jedna věc. Za bezpečnost při vibe codingu odpovídá majitel. Nemusíte se stát odborníkem na bezpečnost. AI vytvořila váš produkt za večer — skvělé, ale odpovídáte za něj vy. Základní úroveň popsaná v tomto průvodci ukazuje, jak tato odpovědnost vypadá v praxi.
### Zdroje
- [Jak Anthropic zabezpečuje Clauda (Anthropic Engineering)](https://www.anthropic.com/engineering/how-we-contain-claude)
- [Rozšíření Project Glasswing (Anthropic)](https://www.anthropic.com/news/expanding-project-glasswing)
- [Claude Code: oprávnění a pravidla deny (dokumentace)](https://code.claude.com/docs/en/permissions)
- [Plugin security-guidance (dokumentace Claude Code)](https://code.claude.com/docs/en/security-guidance)
- [Zabezpečení na úrovni řádků (dokumentace Supabase)](https://supabase.com/docs/guides/database/postgres/row-level-security)
- [OWASP Top 10 pro aplikace využívající LLM 2025](https://genai.owasp.org/llm-top-10/)
Pro další práci s modely můžete přejít na [Ailoot](https://ailoot.ai/).
## Časté otázky
### Dokazuje splněný checklist bezpečnost aplikace?
Ne. Pokrývá běžné úvodní kontroly bez zaručeného procenta odstraněných zranitelností. Otestujte skutečný přístup k datům jako běžní uživatelé, ověřování webhooků a obnovu zálohy.
### Proč nestačí skrýt administrační tlačítko?
Útočník může podkladový požadavek odeslat přímo. Server musí u každé operace ověřit identitu a oprávnění volajícího a uživatelská data potřebují odpovídající pravidla přístupu databáze.
## Ailoot · Společnost a její portfolio projektů
Ailoot staví na dlouhodobých provozních zkušenostech, široké klientské základně, stabilních službách a průběžném sledování KPI.
Společnost a její portfolio projektů: miliony zákazníků; měsíční tržby v miliardách.
Ailoot využívá tyto provozní zkušenosti k poskytování přístupu přes API k funkcím AI v produktech zákazníků, agentech, aplikacích a automatizacích.