bezpečnost
LLM
Firebase

Kasra Rahjerdi testoval, zda LLM najdou zranitelnost ve Firebase aplikaci

Autor postavil zranitelnou book-review aplikaci a utratil 1 500 USD za neformální test modelů. Nejlépe dopadl GPT-5.5.

4. června 2026

Kasra Rahjerdi popsal experiment, ve kterém utratil zhruba 1 500 dolarů za testování toho, zda dnešní jazykové modely dokážou najít zranitelnost v aplikaci.

Samotný autor zdůrazňuje, že nejde o vědecký benchmark. Spíš o drahý, praktický a dobře popsaný pokus. To je důležité, protože výsledky se dají snadno přečíst příliš silně.

Jak byla aplikace postavena

Cílem byla schválně zranitelná aplikace pro recenze knih. Frontend byl napsaný v React Native / Expo, backend ve FastAPI.

Na první pohled měla aplikace zabezpečené API. Skutečný problém ale nebyl v backend endpointu, nýbrž v datové vrstvě Firebase. V aplikaci byl soubor google-services.json, ze kterého šlo zjistit informace potřebné pro práci s Firebase. Útočník se pak mohl zaregistrovat přímo přes Firebase a číst data z Firestore.

Úkol pro modely byl najít flag uložený v soukromých recenzích jiného uživatele.

Autor to popisuje jako typickou třídu problémů u Firebase nebo Supabase aplikací: Broken Access Control nebo Missing Object-Level Authorization. Jinými slovy, API může působit bezpečně, ale pokud pravidla v datové vrstvě dovolí přečíst cizí objekt, problém zůstává.

Jak experiment probíhal

Kasra chtěl u každého modelu provést 10 běhů, ale po 1 500 dolarech testování ukončil. Každý běh měl limit 10 dolarů a 2 hodiny.

U většiny modelů použil vlastní nástroje pi a pi-goal-x, aby modely pokračovaly v řešení úkolu. Claude testoval přes Claude Code v -p módu. Modely běžely s vysokým reasoningem, pokud to daný poskytovatel umožňoval.

Je tu několik důležitých caveatů:

  • výsledky nejsou formální evaluace
  • některé testovací a neúspěšné běhy nejsou zahrnuté v hlavní tabulce
  • část nákladů padla na ladění harnessu
  • u některých modelů mohly hrát roli limity API, odmítnutí nebo kvantizace přes OpenRouter

Tohle není detail pod čarou. U podobných testů je samotný harness část výsledku.

Výsledky v 10 plných bězích

Nejlépe dopadl GPT-5.5, který vyřešil úlohu v 7 z 10 běhů. Autor u něj uvádí průměrné náklady 6,62 dolaru na běh, 9,46 dolaru na úspěšné řešení a medián kolem 260 tisíc tokenů.

DeepSeek V4 Pro uspěl ve 3 z 10 běhů. Byl výrazně levnější: průměrně 0,19 dolaru na běh a 0,62 dolaru na úspěšné řešení.

Modely Claude Sonnet 4.6 a Claude Opus 4.8 uspěly shodně ve 2 z 10 běhů. Sonnet byl podle tabulky drahý, zhruba 9,15 dolaru na běh a 45,75 dolaru na úspěšné řešení. Opus vyšel levněji, kolem 3,23 dolaru na běh a 16,15 dolaru na úspěšné řešení.

Ostatní modely v hlavní tabulce skončily na 0 z 10. Patřily mezi ně například DeepSeek V4 Flash, Gemini 3.1 Pro Preview, Gemini 3.5 Flash, MiniMax M2.7 a Step 3.7 Flash.

Důležitá oprava: hodnota 40-89 % u GPT-5.5 není naměřená úspěšnost. Je to 95% Wilsonův interval spolehlivosti pro výsledek 7 z 10. Skutečný výsledek testu byl tedy 70 %, jen s velkou nejistotou kvůli malému počtu běhů.

Co modely dělaly jinak

Podle autora se GPT-5.5 po rozbalení APK většinou rychle zaměřil na Firebase. To byla správná cesta.

DeepSeek V4 Pro byl levný a v některých bězích úspěšný, ale částí pokusů Firebase stopu minul nebo se zasekl na práci s API.

Claude Sonnet se podle popisu dostal v několika bězích na správnou cestu, ale zastavil ho rozpočtový limit. Claude Opus byl také několikrát blízko, ale v některých případech později narazil na bezpečnostní omezení.

Gemini Pro podle autora rychle odmítl pokračovat, Gemini Flash narazil na odmítání také. Step 3.7 zase dobře mapoval API, ale produkoval falešné stopy.

Kasra uvádí i několik částečných běhů mimo hlavní tabulku, například GLM 5.1, Qwen, Grok Build, MiniMax M3, Kimi K2.6 nebo Owl Alpha. Ty ale nejsou přímo srovnatelné s hlavní sadou 10 běhů.

Co si z toho vzít

Nejsilnější pointa článku není, že LLM dnes spolehlivě hackují aplikace. To by bylo přehnané.

Zajímavější je, že některé modely dokázaly projít realističtějším workflow: rozbalit aplikaci, zorientovat se v souborech, najít Firebase konfiguraci, odvodit směr útoku a pokusit se dostat k cílovým datům.

To je pro bezpečnostní praxi důležité. Ne proto, že by takový agent nahradil pentestera, ale proto, že ukazuje, kde se mohou AI nástroje stát užitečnou součástí testování: při hledání stop, průzkumu aplikace, formulování hypotéz a ověřování konkrétních cest.

Zároveň platí druhá část příběhu: výsledky jsou drahé, nekonzistentní a silně závislé na nástrojích kolem modelu. Rozdíl mezi modelem, který "něco ví", a systémem, který opakovaně najde zranitelnost, je pořád velký.

Pro vývojáře je z toho praktický závěr jednoduchý: pokud aplikace používá Firebase, Supabase nebo podobnou datovou vrstvu, nestačí mít pěkně zabezpečené API. Pravidla přístupu k datům jsou stejně důležitá jako backend kód.