Lista kontrolna bezpieczeństwa dla aplikacji zbudowanych z AI: co sprawdzić przed startem

Zanim prawdziwi ludzie zaczną korzystać z aplikacji zbudowanej z AI, sprawdź siedem rzeczy: każda strona i każde API sprawdza, kim jest użytkownik i co może zrobić; klucze sekretne znajdują się na serwerze, nigdy w przeglądarce ani w czacie; wszystkie dane wejściowe są walidowane na serwerze; każdy użytkownik może dotrzeć tylko do swoich rekordów; logowanie i kosztowne endpointy mają limity żądań; zależności są aktualne; a ty możesz przywrócić dane, gdy coś pójdzie nie tak. Poniższa lista zamienia każdy z tych punktów w konkretne testy, które można wykonać bez czytania kodu.

Narzędzia do budowy aplikacji z AI dobrze radzą sobie z tym, żeby funkcje działały. Nie są automatycznie ostrożne, bo ostrożność rzadko pojawia się w prompcie. Większość opisanych niżej problemów bierze się z rzeczy, o które nikt nie poprosił, więc poprawka to zwykle po prostu poproszenie o nią.

Jak korzystać z tej listy

Przejdź przez nią po kolei i przy każdym punkcie zrób dwie rzeczy: zapytaj AI, czy to jest obsłużone, i przetestuj to sam. AI może napisać sprawdzenie uprawnień; tylko test pokaże, że działa. Punkty są oznaczone:

• Must — zrób to, zanim ktokolwiek inny użyje aplikacji.
• Should — zrób to, zanim będziesz mieć prawdziwych użytkowników lub prawdziwe dane.
• Later — warto zrobić, gdy aplikacja będzie rosnąć.

Jeśli masz tylko godzinę, zrób wszystkie punkty Must.

1. Uwierzytelnianie: kto to jest?

Uwierzytelnianie oznacza potwierdzenie, kim ktoś jest — zwykle przez logowanie. Podstawy znajdziesz w czym jest uwierzytelnianie, a opcje w jak dodać logowanie do aplikacji.

• Must: Każda strona pokazująca prywatne dane wymaga logowania. Test: wyloguj się, a następnie wklej adres prywatnej strony bezpośrednio do przeglądarki.
• Must: Każdy endpoint API stojący za tymi stronami również wymaga logowania — nie tylko sama strona. Test: wyloguj się, otwórz kartę sieci w narzędziach deweloperskich i ponów żądanie, które aplikacja wysłała, gdy byłeś zalogowany.
• Must: Hasła są przechowywane jako hasz z użyciem wolnego algorytmu haszowania haseł, nigdy jako zwykły tekst. Wytyczne OWASP dotyczące przechowywania haseł zalecają w pierwszej kolejności Argon2id, a jako alternatywy scrypt, bcrypt lub PBKDF2. Zapytaj: „Jak są przechowywane hasła?”.
• Should: Linki do resetowania hasła wygasają i działają tylko raz.
• Should: Ciasteczka sesji są oznaczone Secure, HttpOnly i SameSite, a wylogowanie kończy sesję także na serwerze.
• Later: Zaoferuj uwierzytelnianie dwuskładnikowe lub logowanie przez dostawcę, który je ma.

Sprawdź każdą trasę API i stronę, która zwraca dane użytkownika. Każda z nich musi odrzucać żądania od użytkowników, którzy nie są zalogowani, na serwerze, a nie tylko w kodzie strony. Wypisz trasy, które sprawdziłeś.

2. Autoryzacja: co mogą robić?

Autoryzacja to krok po logowaniu: decydowanie, co dany użytkownik może zobaczyć i zmienić. Tutaj aplikacje zbudowane z AI najczęściej mają poważne dziury, bo aplikacja wygląda poprawnie — panel każdego użytkownika pokazuje tylko jego dane — podczas gdy serwer chętnie wyda cudze dane, jeśli ktoś o nie poprosi bezpośrednio.

• Must: Każdy odczyt, aktualizacja i usunięcie sprawdza na serwerze, że rekord należy do bieżącego użytkownika (lub jego zespołu).
• Must: Przetestuj to: utwórz dwa konta, A i B. Jako A otwórz jeden z rekordów A i zanotuj identyfikator w adresie URL lub żądaniu sieciowym. Zaloguj się jako B i zażądaj tego samego identyfikatora. B musi dostać błąd, a nie dane A.
• Must: Strony administracyjne i endpointy API administracyjne sprawdzają rolę użytkownika na serwerze. Ukrycie linku do administracji to nie ochrona.
• Must: Użytkownicy nie mogą zmienić własnej roli, ceny, salda ani pól właściciela, edytując żądanie. Test: w karcie sieci sprawdź, co wysyła aktualizacja profilu. Jeśli zawiera pola takie jak role lub isAdmin, poproś AI, żeby ignorowało je po stronie klienta.
• Should: Identyfikatory w adresach URL są trudne do odgadnięcia (losowe identyfikatory zamiast 1, 2, 3). To nie zastępuje sprawdzania uprawnień, ale ogranicza szkody, gdy brakuje jednego z nich.

Dla każdego endpointu, który odczytuje lub zmienia rekord, sprawdź na serwerze, czy zalogowany użytkownik jest jego właścicielem lub ma prawo do dostępu. Jeśli nie, zwróć 404. Następnie pokaż mi, jak przetestowałbyś to na dwóch kontach.

3. Dostęp do wierszy w bazie danych

„Dostęp na poziomie wiersza” oznacza, że każdy wiersz tabeli (jedna rezerwacja, jedna faktura) jest widoczny tylko dla użytkowników, do których należy. Są dwa częste sposoby egzekwowania tego:

Obie metody można zrobić dobrze. Ważne jest, by:

• Must: Jeśli przeglądarka rozmawia z bazą danych bezpośrednio (niektóre hostowane produkty bazodanowe na to pozwalają), reguły dostępu na poziomie wiersza są włączone dla każdej tabeli. Bez nich każdy, kto ma publiczny klucz, może odczytać całą tabelę.
• Must: Zapytania filtrują po bieżącym użytkowniku lub zespole, a nie po identyfikatorze wysłanym przez przeglądarkę.
• Should: Dane współdzielone (projekty zespołu) mają jasną regułę, kto należy do zespołu, egzekwowaną w jednym miejscu.

4. Sekrety i klucze API

Klucz API to hasło do usługi. Stripe, poczta e-mail i dostawcy AI korzystają z nich wszyscy. Wprowadzenie znajdziesz w czym są zmienne środowiskowe i sekrety.

• Must: Klucze są przechowywane w zmiennych środowiskowych lub sekretach projektu, nigdy wpisane w kod.
• Must: Klucze, którymi można wydawać pieniądze lub czytać prywatne dane, są używane wyłącznie na serwerze. Test: otwórz swoją działającą stronę, zobacz kod źródłowy strony i pliki JavaScript w narzędziach deweloperskich i wyszukaj początek swojego klucza (na przykład sk_). Nie może się tam pojawić.
• Must: Klucze nigdy nie zostały wklejone do czatu, publicznego repozytorium ani na zrzut ekranu. Jeśli tak się stało, zrotuj go u dostawcy (utwórz nowy, usuń stary).
• Should: Używaj kluczy ograniczonych lub o zawężonym zakresie, jeśli dostawca je oferuje. Stripe na przykład zaleca klucze ograniczone, które mają tylko uprawnienia potrzebne integracji.
• Should: Klucze testowe i produkcyjne są oddzielne, a aplikacja produkcyjna używa kluczy produkcyjnych dopiero wtedy, gdy jesteś gotowy.

Niektóre klucze są zaprojektowane jako publiczne — na przykład publishable key Stripe (pk_…) albo klucz do map ograniczony do twojej domeny. Zasada dotyczy kluczy, które dają moc, a nie każdego ciągu znaków wyglądającego jak klucz.

5. Walidacja danych wejściowych

Wszystko, co wysyła użytkownik — pola formularzy, przesyłane pliki, parametry w adresie URL — może być czymkolwiek, a nie tylko tym, na co pozwala formularz.

• Must: Walidacja odbywa się na serwerze, nie tylko w przeglądarce. Sprawdzenia w przeglądarce są dla wygody; każdy może je ominąć.
• Must: Zapytania do bazy danych używają parametrów, a nie tekstu sklejonego z danych wejściowych użytkownika (to zapobiega SQL injection). Poproś AI o potwierdzenie.
• Must: Tekst wpisany przez użytkowników jest wyświetlany jako tekst, a nie uruchamiany jako HTML. Test: wpisz <b>cześć</b> jako swoje imię. Powinieneś zobaczyć znaczniki, a nie pogrubiony tekst.
• Should: Przesyłanie plików sprawdza typ i rozmiar, a przesłane pliki nie są serwowane z głównej domeny aplikacji jako uruchamialne strony.
• Should: Błędy pokazywane użytkownikom są proste („Coś poszło nie tak”); szczegółowe błędy trafiają tylko do logów serwera.
• Should: Webhooki z usług takich jak Stripe weryfikują podpis dostawcy, zanim cokolwiek zrobią. Zobacz czym jest webhook.

Dodaj walidację po stronie serwera do każdego formularza i endpointu API: pola wymagane, długości, formaty i dozwolone wartości. Odrzucaj wszystko inne z jasnym komunikatem. Nie pokazuj użytkownikom wewnętrznych szczegółów błędów.

6. Limity żądań i nadużycia

Limit żądań ogranicza, ile żądań ktoś może wysłać w danym okresie. Bez nich każdy może zgadywać hasła przez cały dzień, zalać formularz rejestracji lub podbić rachunek za płatne API.

• Must: Logowanie, rejestracja i reset hasła mają limity żądań na adres IP i na konto.
• Must: Wszystko, co kosztuje cię pieniądze za wywołanie — żądania do modeli AI, SMS, e-mail — ma limit na użytkownika i wymaga logowania.
• Should: Publiczne formularze (kontakt, lista oczekujących) mają ochronę przed spamem: limit żądań, ukryte pole-pułapkę (honeypot) lub CAPTCHA.
• Should: Ustaw limity wydatków lub alerty u płatnych dostawców, tak aby błąd lub atakujący nie mógł wygenerować nieograniczonego rachunku.

7. Zależności

Aplikacje są budowane z pakietów open source, a pakiety czasem mają znane luki.

• Should: Poproś AI o sprawdzenie znanych podatności (dla projektów JavaScript npm audit lub odpowiednik w twoim menedżerze pakietów) i aktualizację tego, co jest dotknięte.
• Should: Usuń pakiety, których aplikacja już nie używa.
• Should: Uważaj na pakiety z bardzo małą liczbą użytkowników lub z nazwami przypominającymi literówki popularnych pakietów.
• Later: Sprawdzaj co miesiąc lub dwa, albo włącz automatyczne alerty, jeśli twój kod jest na GitHubie.

8. Kopie zapasowe i odzyskiwanie

Bezpieczeństwo obejmuje możliwość odzyskania się po błędach — twoich, AI lub atakującego.

• Must: Wiedz, gdzie znajdują się twoje dane i czy są tworzone ich kopie zapasowe. Nie zakładaj tego; sprawdź dokumentację swojego hosta.
• Should: Rób własny, okresowy eksport ważnych danych (na przykład funkcję eksportu do CSV lub zrzut bazy) i przechowuj go osobno.
• Should: Trzymaj kod w systemie kontroli wersji, aby można było przywrócić dowolną wersję.
• Should: Działania nieodwracalne (usunięcie konta, usunięcie projektu) wymagają potwierdzenia, a warto rozważyć „miękkie usuwanie”, które da się cofnąć przez pewien czas.
• Later: Raz faktycznie przetestuj przywracanie. Kopia zapasowa, której nigdy nie przywróciłeś, to nadzieja, a nie plan.

9. Przed startem

• Must: Działająca strona używa HTTPS wszędzie.
• Must: Dane przykładowe, konta testowe i strony debugowania z etapu developmentu są usunięte.
• Should: Polityka prywatności mówi, jakie dane zbierasz i po co — w wielu miejscach jest wymagana, gdy zbierasz dane osobowe. Nie deklaruj certyfikatów (SOC 2, HIPAA), których nie masz.
• Should: Masz sposób, by można się z tobą skontaktować w sprawie zagrożeń bezpieczeństwa, i wiesz, jak szybko zrotować każdy klucz.

Szerszy przegląd przed startem, wykraczający poza bezpieczeństwo, znajdziesz w jak przenieść prototyp AI na produkcję.

Kiedy zlecić profesjonalny przegląd

Lista kontrolna wyłapuje typowe błędy; nie zastępuje eksperta. Rozważ opłacony przegląd, jeśli sam przetwarzasz numery kart zamiast przez hostowany checkout, przechowujesz dane zdrowotne, finansowe lub dane dzieci, sprzedajesz firmom, które wymagają ankiet bezpieczeństwa, albo wyciek poważnie by ci zaszkodził. Możliwość wyeksportowania kodu znacznie ułatwia taki przegląd.

Bezpieczeństwo przy budowie w Mythex

Mythex nie ma panelu skanowania bezpieczeństwa, więc powyższa lista to proces, którego należy się trzymać. Kilka rzeczy, które pomagają:

• Sekrety projektu. Przechowuj klucze w ustawieniach projektu → Secrets lub przez kartę z sekretami, którą agent pokazuje w czacie, aby nie trafiły do kodu ani do wiadomości. Po zmianie sekretu dla działającej aplikacji opublikuj ją ponownie.
• Tryby Plan i Ask. Poproś agenta o przegląd uprawnień bez edycji: „W trybie Ask wypisz każdą trasę API i to, jakie sprawdzenie uprawnień wykonuje”.
• /test każe agentowi przeklikać twój podgląd jako użytkownik — przydatne do testu z dwoma kontami z sekcji 2.
• Checkpointy pozwalają cofnąć zmianę, która coś zepsuła.

Zobacz Bezpieczeństwo aplikacji, które budujesz oraz Zmienne środowiskowe i sekrety w dokumentacji. Jeśli następnie dodajesz konta użytkowników, przeczytaj jak dodać logowanie do aplikacji.

Pytania