Penetration testování webu pomocí Claude Code před spuštěním

Postup: v izolovaném prostředí pověříte Claude Code s modelem Opus 5.5 rolí útočníka, rozdělíte útoky do tří skupin a každý necháte reálně spustit a zalogovat. Nálezy pak opravíte a ověříte regresními testy. Penetration testování webu tak lze před spuštěním částečně zrychlit, lidská kontrola ale zůstává nutná po celou dobu.

Jak funguje penetration testování webu se třemi podagenty a účty A, B a admin?

Pentest pomocí AI stojí na simulovaném etickém hackerovi: model Opus 5.5 dostane roli útočníka a projíždí web proti předem danému seznamu útoků. Je to praktický bezpečnostní audit webu, který lze pustit ještě před ostrým provozem. Práci rozdělíte na tři podagenty (subagents), jeden na každou skupinu útoků. Každý podagent dostane vlastní sadu tří testovacích účtů: běžného uživatele A, běžného uživatele B a administrátora. Podagenti jen útočí a zaznamenávají – neopravují.

Tento princip je blízký tomu, co řešíme při nasazení AI agentů: oddělené role, jasný rozsah a žádné tiché zásahy do produkčního kódu.

flowchart TD
    A["Člověk: rozsah a pravidla"] --> B["Opus 5.5: etický hacker"]
    B --> C["Podagent 1: impersonace"]
    B --> D["Podagent 2: limity a validace"]
    B --> E["Podagent 3: útoky zvenčí"]
    C --> F["Report s logy"]
    D --> F
    E --> F
    F --> G["Člověk: validace a oprava"]

Proč právě tři účty

Tři účty pokrývají tři různé úhly pohledu. Účet A a účet B odhalí, jestli jeden uživatel vidí nebo mění data druhého – to je jádro IDOR (Insecure Direct Object Reference). Administrátorský účet ověří, zda běžný uživatel nedosáhne na privilegované funkce. Hesla testovacích účtů patří do souboru .env mimo Git a tokeny se v reportu maskují.

Úroveň úsilí podle skupiny

Výchozí úroveň úsilí medium na většinu skupin stačí; Anthropic ji v přehledu modelů uvádí jako výchozí, pokud nenastavíte jinak. Skupinu impersonace doporučujeme zvednout na high – chyba v oprávněních je nejdražší omyl, protože vede přímo k úniku cizích dat.

Jaké skupiny útoků je potřeba pokrýt?

Útoky rozdělíte do tří skupin podle toho, odkud útočník přichází a co se snaží obejít. Každá skupina má vlastního podagenta a vlastní sadu účtů, takže se nálezy nemíchají dohromady.

Impersonace a práva

Podagent se bez přihlášení pokusí vzít veřejný klíč z frontendu a dotázat se přímo na tabulky databáze. Přihlášený jako A zamění id v požadavku za B a zkusí číst, upravit i smazat cizí data. Do požadavku na úpravu profilu přidá role: admin. Resetovací odkaz na heslo použije dvakrát za sebou.

Limity v rozhraní a validace

U zakázaných tlačítek a skrytých voleb podagent přeskočí stránku a pošle požadavek přímo na API. Po vyčerpání bezplatného využití ověří, zda přímé volání stále projde. Při malém kreditu vystřelí 20 souběžných požadavků. Formuláře plní extrémními vstupy a mění přesměrování ?next= na cizí web, včetně hodnot začínajících // a @.

Útoky zvenčí

Sem patří XSS payload v uživatelském jménu, komentáři nebo Markdownu, SSRF přes zadané URL a prompt injection v nahraném dokumentu. SSRF a funkce s načítáním URL se testují jen tehdy, pokud je aplikace opravdu má.

Kategorie jako IDOR a cross-file SSRF plugin security-guidance uvádí mezi svými sledovanými vzory.

Proč musí být každý útok reálně spuštěn a doložen?

Útok, který se jen přečetl v kódu a nikdy nespustil, se počítá jako neprokázaný. Pouhý úsudek nad zdrojákem přehlédne chování runtime, konfiguraci a datové toky. Důkazem je log požadavku a odpovědi, ne věta „podle kódu by to mělo být v pořádku“.

Takto vypadá jeden uložený regresní test pro IDOR, který se dá pustit opakovaně:

# Test IDOR: účet A se pokouší číst objednávky účtu B
# Očekávaný výsledek po opravě: HTTP 403
TOKEN_A="$TEST_TOKEN_A"   # z .env, mimo Git
curl -s -o /dev/null -w "%{http_code}\n" \
  -H "Authorization: Bearer $TOKEN_A" \
  "https://staging-security.example/api/users/B/orders"

Jak izolovat testovací prostředí, aby agenti nezasáhli produkci?

Ochrana nesmí stát na jediné větě v promptu. Oficiální dokumentace Claude Code k bezpečnosti doporučuje kombinovat permissions a sandboxing tak, aby dopad byl omezený i tehdy, když prompt injection obejde rozhodování agenta.

Režim bypassPermissions, respektive --dangerously-skip-permissions, dokumentace k oprávněním označuje za vhodný jen pro prostředí, kde agent nemůže nic poškodit. Vývojový kontejner sám o sobě nestačí – Anthropic upozorňuje, že nezabrání exfiltraci všeho, co je do něj zpřístupněno, včetně přihlašovacích údajů v ~/.claude.

Náš vlastní provoz běží na Railway s Next.js a PostgreSQL a testovací prostředí od produkce oddělujeme. Pro české startupy s AI generovaným kódem z toho plyne jednoduché pravidlo: produkční a testovací databáze i DNS zóny držte v odlišných účtech.

Kolik takový test stojí v tokenech?

Krátká odpověď: u běžné webové aplikace řádově desítky USD za jednu dávku, u rozsáhlého repozitáře s opakovanými opravami až stovky. Přesné číslo bez změření skutečné spotřeby nikdo poctivě neuvede.

Podle ceníku Anthropic stojí Opus 5.5 4 USD za milion vstupních a 20 USD za milion výstupních tokenů. Jeden agent se 300 000 vstupními a 50 000 výstupními tokeny tak vychází zhruba na 2,20 USD podle stejného ceníku.

Částky jsou přepočtené z jednotkových cen v ceníku Anthropic; jde o modelové kalkulace, ne garantované ceny.

Do rozpočtu patří i to, co se v tabulce neobjeví: opakované načítání stejných souborů, dlouhé reporty a patche, regresní testy, infrastruktura sandboxu a hlavně lidská kontrola nálezů. Cena „high-effort podagenta“ jako oficiální položka neexistuje.

Plugin security-guidance a limity AI testování

Plugin nainstalujete příkazem /plugin install security-guidance@claude-plugins-official. Po každém tahu úprav a po commitu pak Opus změny znovu zkontroluje, což spotřebovává další využití. Právě takhle zapojujeme bezpečnostní vrstvy do AI ve vývojovém procesu.

Co plugin skutečně kontroluje

Podle README pluginu pracuje ve třech vrstvách: varování podle vzorů při operacích Edit a Write, LLM kontrola diffu po dokončení tahu a agentní kontrola commitu, která čte související soubory a sleduje datové toky napříč projektem. README uvádí zhruba 25 známých nebezpečných vzorů – mezi příklady patří yaml.load, innerHTML, hardcodované secrets, IDOR i cross-file SSRF.

Veřejná issues z 13. a 18. srpna 2026 ale ukázala limity: chybu ve zpracování glob vzorů, kdy ** vynechá soubory v kořenovém adresáři, a tiché zahození všech uživatelských vzorů při syntakticky validní, ale chybně strukturované konfiguraci. Plugin proto berte jako pomocnou vrstvu, ne jako důkaz bezpečnosti.

Kde AI selhává oproti etickému hackerovi

Etický hacker AI je užitečný pomocník, ale agent analyzuje jen to, k čemu má přístup. Neznámá API, dynamické routy a chyby v infrastruktuře mu uniknou. Slabší je v obchodní logice – IDOR, zneužití workflow a závody často vyžadují kreativní hypotézu a zkušenost. K tomu přistupuje riziko nebezpečné opravy a prompt injection z nedůvěryhodného obsahu.

Časté otázky

Nahradí pentest pomocí AI klasický pentest?

Ne. AI penetration testing je rychlá pomocná kontrola, ne náhrada autorizovaného pentestu. Agent pokryje známé vzory a mnoho útoků paralelně, ale uniká mu obchodní logika, neznámá API a kombinace slabých signálů do skutečného útoku. Zkušený etický hacker mění strategii podle chování aplikace a posoudí reálný dopad. Nejbezpečnější je kombinace: agenti analyzují, člověk stanoví rozsah, validuje nálezy a schvaluje opravy.

Které 14 kategorií zranitelností si definovat pro vlastní test?

Postavte seznam na ověřitelných kategoriích: autentizace, autorizace, IDOR, SSRF, XSS, SQL injection, command injection, insecure deserialization, path traversal, správa secrets, CSRF, bezpečnostní hlavičky, zranitelnosti závislostí a misconfiguration. Každá kategorie potřebuje konkrétní postup, očekávaný výsledek a lidskou validaci. Oficiální závazný seznam o 14 položkách neexistuje, proto si ho sestavte sami a u každé položky dokládejte log.

Dá se test spustit proti produkčnímu webu?

Nedoporučujeme to. Agenti mažou a upravují data, střílejí souběžné požadavky a zkoušejí open redirect – na produkci to znamená riziko pro reálné uživatele. Test pusťte proti oddělenému prostředí se syntetickými daty a deny-all egress. Před každým během ověřte cílové hostname a IP, po skončení smažte testovací účty a zneplatněte credentials.

Musím používat nejdražší model a high effort pro všechny podagenty?

Ne. U Opus 5.5 je výchozí úroveň úsilí medium a na většinu skupin stačí. Na high zvedněte jen skupinu impersonace, protože chyba v oprávněních je nejdražší omyl. Vyšší úsilí zdražuje tím, že model dělá delší analýzu a víc iterací, proto spotřebu tokenů raději měřte. Test zranitelností před spuštěním tak zůstane cenově předvídatelný.