Lista kontrolna bezpieczeństwa aplikacji webowych

Praktyczna, niezależna od dostawcy lista kontrolna dla każdego, kto wdraża aplikację webową, niezależnie od tego, czy napisał każdą linijkę ręcznie, czy zbudował ją, promptując AI ("vibe coding"). AI pisze kod, który przechodzi ścieżkę szczęśliwą, a mimo to zostawia prawdziwe dziury, więc działająca funkcja niczego nie dowodzi w kwestii bezpieczeństwa. Ta lista to to, co warto faktycznie sprawdzić przed i po publikacji.

Jest uporządkowana według kategorii. Zacznij od dowolnej lub przechodź je po kolei. Każda strona zawiera konkretne sprawdzenia: co przetestować, dlaczego to ważne i jak to naprawić.

Jak z niej korzystać

Traktuj każdą pozycję jako test, a nie lekturę. Spróbuj ataku, a potem potwierdź poprawkę.
Testuj z nieprawidłowymi danymi i jako niewłaściwy użytkownik, a nie tylko w normalnym przepływie.
Gdy kod wygląda poprawnie, uruchom skan wdrożonego adresu URL, aby wychwycić wszystko, co przestało działać między kolejnymi promptami.

Kategorie

Uwierzytelnianie i sesje: jak ludzie udowadniają, kim są, i jak utrzymujesz ich zalogowanych, nie pozwalając ukraść tokenu.
Autoryzacja i kontrola dostępu: upewnienie się, że zalogowany użytkownik nie może odczytać ani zmienić danych, które nie są jego (IDOR, izolacja najemców).
Walidacja danych wejściowych i wstrzyknięcia: SQL injection, XSS, SSRF, niebezpieczna deserializacja i przesyłanie plików.
API i żądania: CSRF, CORS, mass assignment i ataki na kształt żądania.
Sekrety i ochrona danych: klucze, szyfrowanie w spoczynku i w tranzycie, dane osobowe i prawa do danych.
Dostępność i nadużycia: ograniczanie liczby żądań, odmowa usługi i niekontrolowane zużycie zasobów.
Infrastruktura i wdrożenie: porty i zapory, kontenery, wystawione panele administracyjne, nagłówki zabezpieczeń i TLS.
Zależności, logowanie i proces: łańcuch dostaw, sekrety w git, logowanie zdarzeń, niezależne testy.

Krótka wersja

Jeśli masz tylko godzinę, sprawdź najpierw tych pięć rzeczy. To najczęstsze i najbardziej szkodliwe problemy w rzeczywistych audytach:

Zerwana kontrola dostępu. Zaloguj się jako użytkownik A i zażądaj obiektu użytkownika B po identyfikatorze. Jeśli zostanie zwrócony, masz dziurę. Zobacz autoryzację.
Sekrety w kliencie lub w git. Przeszukaj paczkę przeglądarki i repozytorium pod kątem kluczy. Wszystko, co zostało zatwierdzone w git, jest skompromitowane. Zobacz sekrety.
Brak ograniczenia liczby żądań przy logowaniu. Bez tego ataki brute force są trywialne. Zobacz dostępność.
Brak ochrony przed CSRF lub login-CSRF. Zobacz API i żądania.
Porty otwarte poza zaporą. Kontenery często publikują porty z pominięciem zapory. Zobacz infrastrukturę.

Tę listę publikuje zespół Arc OS. Stosujemy ją wobec własnego produktu, a Ty możesz z niej korzystać przy swoim. To punkt wyjścia, a nie certyfikacja, i nie zastępuje niezależnego testu penetracyjnego.