Bezpečnostní kontrolní seznam pro aplikace stavěné pomocí AI: co zkontrolovat před spuštěním

Než aplikaci postavenou pomocí AI začnou používat skuteční lidé, zkontrolujte sedm věcí: každá stránka a každé API ověřuje, kdo uživatel je a co smí dělat; tajné klíče žijí na serveru, nikdy v prohlížeči nebo v chatu; všechny vstupy se validují na serveru; každý uživatel se dostane jen ke svým záznamům; přihlášení a drahé koncové body mají limity požadavků; závislosti jsou aktuální; a dokážete obnovit svá data, když se něco pokazí. Níže každou z těchto věcí převádíme na konkrétní testy, které lze provést bez čtení kódu.

Nástroje pro tvorbu aplikací pomocí AI jsou dobré v tom, aby funkce fungovaly. Automaticky opatrné nejsou, protože „opatrnost“ se v zadání málokdy objeví. Většina níže popsaných problémů vzniká věcmi, na které se nikdo neptal, takže oprava bývá obvykle v tom, že se zeptáte.

Jak používat tento kontrolní seznam

Projděte ho postupně a u každé položky udělejte dvě věci: požádejte AI, aby se o to postarala, a otestujte to sami. AI napíše kontrolu oprávnění; jen test vám řekne, že funguje. Položky jsou označené takto:

• Nutné — udělejte to, než aplikaci použije kdokoli jiný.
• Měli byste — udělejte to, než budete mít skutečné uživatele nebo skutečná data.
• Později — stojí za to udělat, až aplikace poroste.

Pokud máte jen hodinu, udělejte všechny Nutné položky.

1. Autentizace: kdo to je?

Autentizace znamená ověřit, kdo někdo je, obvykle přihlášením. Základy najdete v co je autentizace a možnosti v jak přidat přihlášení do aplikace.

• Nutné: Každá stránka, která zobrazuje soukromá data, vyžaduje přihlášení. Test: odhlaste se, pak vložte URL soukromé stránky přímo do prohlížeče.
• Nutné: Každý koncový bod API za těmito stránkami také vyžaduje přihlášení, ne jen stránka. Test: odhlaste se, otevřete v prohlížeči záložku sítě a zopakujte požadavek, který aplikace odeslala, když jste byli přihlášeni.
• Nutné: Hesla se ukládají jako hash pomocí pomalého algoritmu pro hashování hesel, nikdy v prostém textu. Pokyny OWASP pro ukládání hesel doporučují nejdřív Argon2id, jako alternativy scrypt, bcrypt nebo PBKDF2. Zeptejte se: „Jak se ukládají hesla?“
• Měli byste: Odkazy pro obnovení hesla vyprší a fungují jen jednou.
• Měli byste: Cookies relace jsou označené Secure, HttpOnly a SameSite a odhlášení ukončí relaci na serveru.
• Později: Nabídněte dvoufaktorové ověření, nebo přihlášení přes poskytovatele, který ho má.

Zkontrolujte každou trasu API a stránku, která vrací uživatelská data. Každá musí na serveru, ne jen v kódu stránky, odmítnout požadavky od uživatelů, kteří nejsou přihlášeni. Vypište trasy, které jste zkontrolovali.

2. Autorizace: co smějí dělat?

Autorizace je krok po přihlášení: rozhodnout, co smí tento konkrétní uživatel vidět a měnit. Tady mívají aplikace z AI nejčastěji vážné díry, protože aplikace vypadá správně — přehled každého uživatele ukazuje jen jeho data — zatímco server vydá data kohokoli, pokud je o ně požádáte přímo.

• Nutné: Každé čtení, aktualizace a smazání ověří na serveru, že záznam patří aktuálnímu uživateli (nebo jeho týmu).
• Nutné: Test: vytvořte dva účty, A a B. Jako A otevřete jeden ze záznamů A a poznamenejte si ID v URL nebo v síťovém požadavku. Přihlaste se jako B a požádejte o stejné ID. B musí dostat chybu, ne data A.
• Nutné: Administrátorské stránky a administrátorské koncové body API kontrolují roli uživatele na serveru. Skrytí odkazu na administraci není ochrana.
• Nutné: Uživatelé nemohou změnit svou roli, cenu, zůstatek ani pole vlastníka úpravou požadavku. Test: v záložce sítě se podívejte, co odesílá aktualizace profilu. Pokud obsahuje pole jako role nebo isAdmin, požádejte AI, aby je z klienta ignorovala.
• Měli byste: ID v URL jsou těžko uhodnutelná (náhodná ID místo 1, 2, 3). Nenahrazují kontroly oprávnění, ale omezují škodu, když některá chybí.

U každého koncového bodu, který čte nebo mění záznam, zkontrolujte na serveru, že přihlášený uživatel záznam vlastní nebo k němu smí přistupovat. Pokud ne, vraťte 404. Potom mi ukažte, jak byste to otestovali se dvěma účty.

3. Přístup na úrovni řádků v databázi

„Přístup na úrovni řádků“ znamená, že každý řádek tabulky (jedna rezervace, jedna faktura) je viditelný jen uživatelům, ke kterým patří. Existují dva běžné způsoby, jak to vynutit:

Oběma se dá dělat dobře. Důležité je:

• Nutné: Pokud prohlížeč komunikuje s databází přímo (některé hostované databázové produkty to umožňují), jsou pravidla pro řádky zapnutá pro každou tabulku. Bez nich může kdokoli s veřejným klíčem číst celou tabulku.
• Nutné: Dotazy filtrují podle aktuálního uživatele nebo týmu, ne podle ID, které pošle prohlížeč.
• Měli byste: Sdílená data (projekty týmu) mají jasné pravidlo, kdo je v týmu, vynucované na jednom místě.

4. Tajné klíče a klíče API

Klíč API je heslo ke službě. Stripe, e-mail i poskytovatelé AI je používají. Pozadí najdete v co jsou proměnné prostředí a tajné klíče.

• Nutné: Klíče jsou uložené v proměnných prostředí nebo tajných klíčích projektu, nikdy zapsané v kódu.
• Nutné: Klíče, kterými lze utrácet peníze nebo číst soukromá data, se používají jen na serveru. Test: otevřete svůj živý web, zobrazte zdrojový kód stránky a soubory JavaScriptu v nástrojích pro vývojáře a hledejte začátek svého klíče (například sk_). Nesmí se tam objevit.
• Nutné: Klíče nebyly nikdy vloženy do chatu, veřejného repozitáře ani na snímek obrazovky. Pokud ano, otočte je u poskytovatele (vytvořte nový a starý smažte).
• Měli byste: Používejte omezené nebo rozsahově vymezené klíče, pokud je poskytovatel nabízí. Stripe například doporučuje omezené klíče, které mají jen oprávnění potřebná pro vaši integraci.
• Měli byste: Testovací a živé klíče jsou oddělené a živá aplikace používá živé klíče až ve chvíli, kdy jste připraveni.

Některé klíče jsou určené k veřejnému použití — veřejný klíč Stripe (pk_…) nebo klíč pro mapy omezený na vaši doménu. Pravidlo se týká klíčů, které dávají moc, ne každého řetězce, který klíči vypadá.

5. Validace vstupů

Cokoli, co uživatel pošle — pole formuláře, nahrané soubory, parametry v URL — může být čímkoli, ne jen tím, co váš formulář dovoluje.

• Nutné: Validace probíhá na serveru, ne jen v prohlížeči. Kontroly v prohlížeči slouží pohodlí; kdokoli je může přeskočit.
• Nutné: Dotazy do databáze používají parametry, ne text slepený z uživatelského vstupu (tím se brání SQL injection). Požádejte AI, aby to potvrdila.
• Nutné: Text, který uživatelé zadají, se zobrazuje jako text, ne se spouští jako HTML. Test: zadejte <b>ahoj</b> jako své jméno. Měli byste vidět značky, ne tučný text.
• Měli byste: Nahrané soubory kontrolují typ a velikost a nahrané soubory se neobsluhují z hlavní domény aplikace jako spustitelné stránky.
• Měli byste: Chyby zobrazené uživatelům jsou prosté („Něco se pokazilo“); podrobné chyby jdou jen do serverových logů.
• Měli byste: Webhooky od služeb jako Stripe ověřují podpis poskytovatele, než něco udělají. Viz co je webhook.

Přidejte serverovou validaci ke každému formuláři a koncovému bodu API: povinná pole, délky, formáty a povolené hodnoty. Cokoli jiného odmítněte s jasnou zprávou. Uživatelům neukazujte interní podrobnosti chyb.

6. Limity požadavků a zneužití

Limit požadavků omezuje, kolik požadavků může někdo poslat za období. Bez nich může kdokoli celý den hádat hesla, zaplavit váš registrační formulář nebo navyšovat účet za placené API.

• Nutné: Přihlášení, registrace a obnovení hesla mají limit požadavků na IP adresu i na účet.
• Nutné: Cokoli, co vás stojí peníze za volání — požadavky na AI model, SMS, e-mail — má limit na uživatele a vyžaduje přihlášení.
• Měli byste: Veřejné formuláře (kontakt, čekací listina) mají ochranu proti spamu: limit požadavků, skryté pole pro boty nebo CAPTCHA.
• Měli byste: U placených poskytovatelů nastavte stropy výdajů nebo upozornění, aby chyba nebo útočník nevytvořil neomezený účet.

7. Závislosti

Aplikace se skládají z open-source balíčků a balíčky občas mají známé zranitelnosti.

• Měli byste: Požádejte AI, aby zkontrolovala známé zranitelnosti (u projektů v JavaScriptu npm audit nebo ekvivalent pro váš správce balíčků) a aktualizovala, co je zasažené.
• Měli byste: Odstraňte balíčky, které aplikace už nepoužívá.
• Měli byste: Buďte opatrní s balíčky s velmi malým počtem uživatelů nebo s názvy, které vypadají jako překlepy populárních.
• Později: Kontrolujte každý měsíc nebo dva, nebo zapněte automatická upozornění, pokud je váš kód na GitHubu.

8. Zálohy a obnova

Bezpečnost zahrnuje schopnost zotavit se z chyb — vašich, AI nebo útočníka.

• Nutné: Vězte, kde jsou vaše data a zda se zálohují. Nepředpokládejte to; zkontrolujte dokumentaci svého hostingu.
• Měli byste: Mějte vlastní pravidelný export důležitých dat (například funkci exportu do CSV nebo výpis databáze) uložený odděleně.
• Měli byste: Ukládejte kód do verzovacího systému, aby šla obnovit kterákoli verze.
• Měli byste: Destruktivní akce (smazání účtu, smazání projektu) žádají o potvrzení a zvažte „měkké smazání“, které lze chvíli vrátit zpět.
• Později: Jednou skutečně otestujte obnovu. Záloha, kterou jste nikdy neobnovili, je naděje, ne plán.

9. Před spuštěním

• Nutné: Živý web používá všude HTTPS.
• Nutné: Ukázková data, testovací účty a ladicí stránky z vývoje jsou odstraněné.
• Měli byste: Zásady ochrany osobních údajů říkají, jaká data sbíráte a proč — v mnoha zemích je to povinné, pokud sbíráte osobní údaje. Netvrďte certifikace (SOC 2, HIPAA), které nemáte.
• Měli byste: Máte způsob, jak vás lze kontaktovat o bezpečnostních problémech, a víte, jak rychle otočit každý klíč.

Pro širší kontrolu před spuštěním nad rámec bezpečnosti viz jak dostat prototyp z AI do produkce.

Kdy si vyžádat odbornou kontrolu

Kontrolní seznam zachytí běžné chyby, ale odborníka nenahradí. Zvažte zaplacení kontroly, pokud zpracováváte čísla karet sami místo přes hostovanou pokladnu, ukládáte zdravotní, finanční nebo dětská data, prodáváte firmám, které žádají bezpečnostní dotazníky, nebo by vás únik vážně poškodil. Možnost exportovat kód tuto kontrolu výrazně usnadní.

Bezpečnost při stavbě na Mythexu

Mythex nemá panel pro bezpečnostní sken, takže postupujte podle výše uvedeného kontrolního seznamu. Pomoci mohou tyto věci:

• Tajné klíče projektu. Ukládejte klíče v nastavení projektu → Tajné klíče nebo přes kartu tajných klíčů, kterou agent ukáže v chatu, aby nebyly v kódu ani ve zprávách. Po změně tajného klíče pro živou aplikaci publikujte znovu.
• Režimy Plan a Ask. Požádejte agenta, aby zkontroloval oprávnění bez úprav: „V režimu Ask vypiš každou trasu API a jakou kontrolu oprávnění provádí.“
• /test nechá agenta projít váš náhled jako uživatel — užitečné pro test se dvěma účty z oddílu 2.
• Checkpointy vám umožní vrátit změnu, která něco rozbila.

Viz Zabezpečení aplikací, které stavíte a Proměnné prostředí a tajné klíče v dokumentaci. Pokud budete dál přidávat uživatelské účty, přečtěte si jak přidat přihlášení do aplikace.

Otázky