Kam vaše aplikace ukládá hesla, když jste ji nepsali vy

Model napsal kód, tlačítka fungují a přihlašování taky. Kde ale skončil e-mail a heslo a kdo se k nim dostane? Čtyři kontroly, které uděláte bez programátora.

Aplikaci jste postavili za víkend. Popsali jste, co má umět, model napsal kód, tlačítka fungují. Přihlašování funguje taky. Zadáte e-mail, přijde vám kód, jste uvnitř.

Otázka, kterou si v tu chvíli nikdo neklade: kde ten e-mail a to heslo skončily a kdo se k nim dostane.

Co je vidět v prohlížeči

Každá aplikace, která běží v prohlížeči, musí někam poslat dotaz na data. K tomu potřebuje adresu a klíč. Model ten klíč do kódu zapíše, protože bez něj by aplikace nefungovala.

Problém je, že kód běžící v prohlížeči není tajný. Kdokoli si ho může otevřít. Stačí pravé tlačítko a Zobrazit zdrojový kód, nebo vývojářské nástroje na kartě Síť. Co tam je, to je veřejné.

Existují dva druhy klíčů. Veřejný, který smí být vidět a sám o sobě nic neotevře, a servisní, který obchází všechna omezení a má přístup ke všemu. Rozdíl mezi nimi je v jednom slově v názvu proměnné. Model ten rozdíl často nezná, protože v datech, ze kterých se učil, jsou oba používané promíchaně.

Když se do prohlížeče dostane servisní klíč, je to stejné, jako byste nalepili klíč od kanceláře na dveře zvenku.

Není to teorie

V březnu 2025 prošel bezpečnostní výzkumník Matt Palmer veřejné aplikace postavené v Lovable. Našel 303 koncových bodů ve více než 170 projektech, které neměly nastavenou ochranu na úrovni databázových řádků. Zranitelnost dostala označení CVE-2025-48757 a zveřejněna byla 29. května 2025.

Co bylo přístupné bez přihlášení:

• jména a e-maily uživatelů
• telefonní čísla
• stav plateb a předplatného
• API klíče, mimo jiné ke Gemini a Google Maps
• přístupové údaje vývojářů

Ty API klíče stojí za zdůraznění. Když někdo najde váš klíč k placené službě, může ji používat na váš účet. Fakturu dostanete vy.

Lovable na to 24. dubna 2025 reagovalo bezpečnostním skenerem. Ten ale jen kontroluje, jestli pravidlo existuje, ne jestli je nastavené správně. Prázdné pravidlo skener projde.

Proč to modely dělají

Veracode v roce 2025 otestoval přes sto jazykových modelů na úlohách v Javě, Pythonu, C# a JavaScriptu. Ve 45 % případů kód neprošel bezpečnostním testem a obsahoval zranitelnost z žebříčku OWASP Top 10.

Rozdíly mezi jazyky:

U jednoho konkrétního typu útoku, kdy se do stránky propašuje cizí skript, selhaly nástroje v 86 % relevantních vzorků.

Důvod je prostý. Model píše kód, který funguje. Nepíše kód, který odolá útoku, protože to po něm nikdo nechtěl. Vy jste napsali „udělej přihlašování", ne „udělej přihlašování, které vydrží, když se někdo bude snažit dostat dovnitř".

A hlavně: chybějící zabezpečení nevypadá jako chyba. Aplikace funguje stejně dobře s ním i bez něj. Rozdíl se projeví až ve chvíli, kdy ji někdo zkusí otevřít jinak, než jste zamýšleli.

Čtyři věci, které si můžete ověřit sami

Nepotřebujete k tomu programátora ani nástroje.

1. Otevřete si zdrojový kód své aplikace. V prohlížeči Ctrl+U. Hledejte slova key, secret, token, password. Jestli za nimi je dlouhý řetězec znaků, je veřejný.

2. Podívejte se na kartu Síť. F12, karta Network, obnovte stránku. Uvidíte každý dotaz, který aplikace posílá. Rozklikněte je a čtěte, co se posílá a co se vrací. Jestli se v odpovědi objeví data jiných uživatelů, máte problém.

3. Odhlaste se a zkuste otevřít odkaz, který vyžaduje přihlášení. Zkopírujte si adresu nějaké vnitřní stránky, otevřete anonymní okno a vložte ji tam. Měli byste skončit na přihlášení.

4. Zkuste se zaregistrovat do aplikace, která je jen pro vás. V červenci 2025 našla bezpečnostní firma Wiz na platformě Base44 dva koncové body, které nevyžadovaly přihlášení. Útočníkovi stačilo znát identifikátor aplikace, který je běžně vidět v adrese a v souboru manifest.json. Pak si prostě vytvořil účet a byl uvnitř. Base44 to opravilo do jednoho dne, ale ta chyba tam do té doby byla.

Co s tím, když něco z toho najdete

Aplikace se kvůli tomu nemusí přepisovat. Ve většině případů je business logika v pořádku a dává smysl, protože jste ji vymysleli vy a víte, jak váš provoz funguje. Opravuje se to, jak aplikace mluví s databází a kde má uložené klíče.

Servisní klíč se přesune na server, kam se z prohlížeče nedá vidět. Nad databází se nastaví pravidla, která říkají, který uživatel smí vidět které řádky. Přihlašování se doplní o ověření na straně serveru, ne jen v prohlížeči.

To je práce na dny, ne na měsíce. A dá se udělat, aniž byste přišli o to, co už funguje.

Klíče, přístupy a zálohy se hlídají průběžně, ne jednou při nasazení. To je běžná součást správy firemního IT.

Série o aplikacích postavených s pomocí AI, díl 1 z 5. Další díl: Kdo se dostane do vaší databáze. Zkuste si to sami.

Nezávazná poptávka  ← Zpět na blog