Hluboká témata

Přístupy a IDOR

Autentizace není autorizace — největší slepé místo vibecoded appek

Login funguje. Uživatel se přihlásí, UI vypadá správně. Ale pod kapotou API ani databáze neověřují, zda přihlášený uživatel smí číst právě tato data. To je IDOR — Insecure Direct Object Reference — a je to nejčastější zranitelnost v aplikacích postavených vibe codingem.

Jak IDOR vypadá v praxi

Tvoje appka má endpoint /api/orders/123. Přihlášený uživatel A si zobrazí svou objednávku. Změní v URL 123 na 124 — a vidí objednávku uživatele B. Login fungoval, ale API nekontroluje vlastnictví záznamu.

AI coding nástroje toto typicky neřeší. Vygenerují funkční CRUD s autentizací (přihlášení), ale autorizaci (kdo smí co vidět) musíš zadat ty.

Moltbook — jak to vypadá ve skutečnosti

Moltbook byla AI sociální síť postavená kompletně vibe codingem. Zakladatel veřejně uvedl, že nenapsal jediný řádek kódu. Výzkumníci z Wiz Research otevřeli stránku v prohlížeči, zmáčkli F12 a v DevTools našli v JavaScript bundlu hardcoded Supabase credentials. S tímto klíčem zavolali Supabase API přímo — bez dalšího přihlášení — a získali plný čtecí i zápisový přístup ke kompletní produkční databázi: 1,5 milionu API tokenů, 35 000 e-mailových adres, soukromé zprávy.

Žádný sofistikovaný útok. Žádný exploit. Jen F12 a veřejně dostupný klíč bez Row Level Security.

Chybový řetězec krok za krokem:

1. Wiz otevřel moltbook.com v prohlížeči a přes DevTools (F12) inspektoval načtené JavaScript soubory.
2. V Next.js static chunku našel hardcoded Supabase credentials: URL projektu + API klíč.
3. S tímto klíčem zavolal Supabase API přímo — bez jakékoli autentizace — a získal plný přístup ke všem tabulkám.
4. Databáze obsahovala 1,5 mil. API tokenů, 35 000 e-mailů a soukromé zprávy.
5. Bonus: za 1,5 mil. „AI agentů“ stálo jen 17 000 lidí (poměr 88:1). Žádný rate limiting, žádná validace.

Supabase a RLS — co AI nástroje neudělají za tebe

Lovable generuje Supabase integraci včetně auth. Ale Row Level Security (RLS) nezapne automaticky — musíš to udělat ručně nebo to zadat AI jako explicitní požadavek.

Tři věci, které Supabase RLS neochrání automaticky:

• service_role klíč v client bundlu — tento klíč obchází RLS kompletně. Nikdy nesmí být ve frontend kódu. Používej ho výhradně na serveru (Edge Functions, backend).
• Views bez security_invoker = true — Supabase Views defaultně obcházejí RLS. Pokud vytvoříš View, musíš explicitně nastavit security_invoker = true, jinak View vrací data všech uživatelů bez ohledu na RLS policies.
• Anon klíč s příliš volnými policies — anon klíč je veřejný (je ve frontend bundlu). RLS policies musí být napsané tak, že s anon klíčem uživatel vidí jen svá vlastní data.

Jak ověřit: negativní test přístupů

Přihlas se jako uživatel A. Pak přes DevTools nebo curl zkus přečíst data uživatele B:

1. Otevři DevTools → Network → najdi API volání na Supabase.
2. Zkopíruj request a změň ID záznamu na záznam jiného uživatele.
3. Pokud dostaneš data — RLS nefunguje.

Pro Supabase konkrétně: přihlas jako user A, pak přes anon klíč zavolej supabase.from('table').select('*') — pokud vrací záznamy jiných uživatelů, RLS není správně nastavený.

Čísla

40–62 % kódu vygenerovaného AI nástroji obsahuje bezpečnostní zranitelnost. Přístupy a IDOR patří mezi nejčastější.

Escape.tech proskenoval 5 600+ vibecoded aplikací a našel 400+ secretů přímo ve frontend kódu (OpenAI, Stripe, Supabase klíče).

Secrets — frontend není trezor

Frontend není trezor, repozitář není trezor, prompt není trezor

API klíč, service-role token nebo databázová URL — pokud je to v kódu, je to veřejné. Tři místa, kde secrets nejčastěji unikají:

1. Frontend JavaScript bundle

Cokoliv v client-side JS si kdokoliv může stáhnout nebo prozkoumat v DevTools. To platí i pro .env proměnné, které framework (Next.js, Vite) vloží do client bundlu — prefix NEXT_PUBLIC_ nebo VITE_ znamená „toto bude veřejné“.

Escape.tech proskenoval 5 600+ vibecoded aplikací a našel 400+ secretů v frontend kódu: OpenAI API klíče, Stripe secret keys, Supabase service_role tokeny.

2. Git historie

Co je v gitu, je tam navždy — i po smazání souboru. Secret commitnutý omylem zůstává v historii repozitáře. Pokud je repo veřejné, stačí git log a secret je venku. I v privátním repu: kdokoliv s přístupem vidí celou historii.

Řešení: .env v .gitignore od prvního commitu. Pokud se secret dostal do git historie, rotuj klíč (vygeneruj nový) — mazání z historie (git filter-branch, BFG) je nespolehlivé.

3. Prompt do AI nástroje

Vložíš API klíč do promptu pro Claude Code, Cursor nebo ChatGPT? Data odchází na cloud servery AI providera. Pokud nemáš opt-out z trénování, klíč se může stát součástí trénovacích dat.

Řešení: AI při generování kódu nepotřebuje znát hodnotu secretu. Stačí jí říct: „pro Stripe použij os.getenv('STRIPE_SECRET_KEY')“. AI napíše kód, který bude proměnnou číst za běhu — samotná hodnota nikdy neopustí tvůj systém směrem k AI provideru.

Checklist před deployem

Před každým nasazením prohledej kód na tyto vzory:

grep -rn "service_role\|sk_live\|sk_test\|OPENAI_API_KEY\|Bearer \|JWT\|SMTP_PASS\|TELEGRAM_TOKEN\|STRIPE_SECRET\|DATABASE_URL\|SUPABASE_SERVICE" --include="*.js" --include="*.ts" --include="*.jsx" --include="*.tsx" --include="*.py" --include="*.env" .

Pokud hledáš ve výstupu Next.js / Vite buildu:

grep -rn "sk_live\|service_role\|OPENAI_API_KEY" .next/ dist/ build/

Pro automatizaci: nastav gitleaks nebo trufflehog v CI/CD — skenují každý commit automaticky.

Správné uložení secrets

Základní pravidlo: .env musí být v .gitignore. .env.example s placeholder hodnotami commitni do repa, aby nový vývojář věděl jaké proměnné potřebuje.

AI nástroje a GDPR

Scanner vidí výstup. Proces tvorby webu může uniknout vedle.

Tvůj klient ti pošle podklady — jméno, e-mail, telefon, IČO, smlouvu. Otevřeš ChatGPT (osobní účet), zkopíruješ text a požádáš o pomoc s článkem na web. Výsledná stránka je čistá: žádný personal data leak v HTML, hezké headery, SSL OK. Ale data klienta už unikla — odešla do OpenAI, kde se mohou stát součástí trénovacího datasetu.

Vibescan tohle nezachytí. Žádný scanner tohle nezachytí. Stalo se to při vývoji, ne v produkci.

Co dělají AI nástroje s tvými prompty

Většina AI služeb v consumer režimu (osobní účet, free/plus tier) defaultně trénuje na uživatelských vstupech. Opt-out je obvykle možný, ale musíš ho aktivně zapnout. Business/Enterprise tiery typicky netrénují by default a nabízejí DPA (Data Processing Agreement).

Chatboti a AI asistenti — trénují na tvých datech?

DPA s AI providery a hostingem

DPA (Data Processing Agreement) je smlouva podle GDPR čl. 28 mezi tebou (správce) a providerem (zpracovatel). Bez DPA nesmíš provideru předávat osobní data klienta v rámci své činnosti. Consumer účty DPA neposkytují — je to business feature.

Lokální alternativa: Ollama

Ollama je výjimka — běží lokálně na tvém počítači, takže data nikdy neopouští systém. Žádné DPA nepotřebuje, žádný opt-out, žádné trénování.

Claude Code lze přesměrovat na lokální Ollama: ANTHROPIC_BASE_URL=http://localhost:11434 (funkční od Ollama v0.14, leden 2026). Kód pak zůstane lokální, ale výkon je výrazně nižší (7B–13B modely vs. Claude Sonnet/Opus).

Praktické omezení: Claude Code posílá ~18 K tokenů systémový prompt — výchozí kontext Ollama (4 K) nestačí. Nastav minimálně 64 K kontext přes Modelfile. Některé pokročilé funkce (prompt caching, count_tokens) nejsou podporovány.

Praktický checklist před každým AI promptem

1. Obsahuje prompt osobní data (klienta, uživatele, zaměstnance)?
2. Pokud ano, používám účet s vypnutým trénováním a s DPA?
3. Pokud ne, mohu data anonymizovat (nahradit reálná jména/kontakty placeholderem)?
4. Pokud anonymizovat nelze, je nutné AI vůbec použít? (Alternativa: lokální Ollama nebo manuálně.)

NIS2 / ZoKB — klientské riziko

Tvoje appka může být něčí rizikový dodavatel

Vibecoded interní nástroj za víkend drží CRM/HR data a běží na osobních AI účtech. Pro tebe je to prototyp. Pro tvého klienta — pokud je regulovaný subjekt — jsi článek v dodavatelském řetězci.

Co je ZoKB

ZoKB (zákon č. 264/2025 Sb.) je česká transpozice EU směrnice NIS2 (2022/2555). Účinný od 1. 11. 2025. Rozšiřuje povinnosti kybernetické bezpečnosti z původních stovek subjektů na 6–10 tisíc organizací v ČR. Dohled: NÚKIB.

Koho se týká

Poskytovatelé regulovaných služeb v 15 sektorech: energetika, doprava, bankovnictví, zdravotnictví, digitální infrastruktura, ICT správa, pitná/odpadní voda, veřejná správa, výroba, poštovní služby, odpady, digitální poskytovatelé (cloud, tržiště) a další.

Základní práh: střední podnik (50+ zaměstnanců, obrat 10M+ EUR). Kritické subjekty bez ohledu na velikost.

Proč se tě týká, i když nejsi regulovaný

NIS2/ZoKB zavádí povinnost řízení dodavatelského řetězce. Regulovaný subjekt musí posoudit bezpečnost svých dodavatelů — včetně tvé appky, pokud zpracovává jeho data.

Tvůj interní nástroj na Supabase + osobní Claude Code účet:

• Zpracovává CRM/HR data klienta, který spadá pod ZoKB.
• Nemá DPA s AI providerem (osobní účet = consumer terms = trénování ON).
• Nemá dokumentovanou bezpečnostní politiku.
• Běží na free tier hostingu bez SLA.

Odpovědnost vedení

ZoKB zavádí osobní odpovědnost vedení: ředitel se nemůže vyvinit tvrzením „o ničem jsem nevěděl“. Pokud schválí nasazení nástroje bez bezpečnostního posouzení, nese odpovědnost.

Pokuta

Co to znamená pro vibecoded appku

Bezpečnostní dokumentace bez bezpečné appky nestačí — a naopak. Pokud tvoje appka zpracovává data pro regulovaný subjekt:

1. Musíš mít DPA s každým AI providerem a sub-procesorem.
2. Musíš mít dokumentovanou bezpečnostní politiku (přístupy, secrets, zálohy, incident response).
3. Firemní AI účty (Team/Enterprise) místo osobních — jinak data klienta mohou jít do trénování.
4. Bezpečnostní testování — minimálně self-review, ideálně SAST/secret scan v CI/CD.

Retence dat — case law

Reálné pokuty bez jediného úniku dat

GDPR čl. 5(1)(e) říká: osobní data smaž, jakmile pominul účel. GDPR ale nestanovuje konkrétní doby — ty vycházejí z judikatury CNIL (francouzský úřad), která se de facto uplatňuje v celé EU.

CNIL pokuty za retenci

Pravidlo „smysluplný kontakt“

Dobu retence „prospect (registrovaný, nekoupil): max. 3 roky od posledního přihlášení“ zpřesnit takto: max. 3 roky od posledního smysluplného kontaktu.

Otevření e-mailu NENÍ platný kontakt (CNIL vs. Spartoo). Platný kontakt = přihlášení, nákup, odeslání formuláře, aktivní interakce.