Lista OWASP to zestawienie najpoważniejszych kategorii ryzyka w aplikacjach webowych, publikowane przez fundację OWASP i opisane identyfikatorami kategorii, nie nazwami błędów. Praktyczna konsekwencja jest taka, że listy nie testuje się punkt po punkcie, lecz używa jej jako kryterium przeglądu architektury aplikacji, modelu uprawnień i zależności.
Na skróty
Czego dowiesz się z artykułu:
- Czym kategoria ryzyka różni się od pojedynczej podatności
- Dlaczego skaner nie potwierdzi zgodności z listą OWASP
- W jakiej kolejności wdrażać zabezpieczenia, żeby nie zacząć od końca
- Gdzie w procesie wytwarzania wpisać testy, żeby nie były jednorazowe
Dla kogo jest ten artykuł:
- Zespoły wytwarzające i utrzymujące aplikacje webowe
- Liderzy techniczni i właściciele produktu odpowiadający za jakość wydania
- Osoby przygotowujące zakres audytu bezpieczeństwa przed zleceniem go na zewnątrz
Czas czytania: 7 minut
Kategoria ryzyka to nie podatność
Najczęstsze nieporozumienie dotyczy samej natury listy. Zestawienie owasp.org grupuje ryzyka w kategorie opisane identyfikatorami w postaci A01:2025, a nie w pojedyncze błędy implementacyjne. Kategoria A01:2025 (złamana kontrola dostępu) obejmuje zarówno brak autoryzacji na endpointcie, jak i możliwość podmiany identyfikatora w żądaniu czy wyciek danych innego użytkownika przez nieprzemyślany filtr.
Podatność jest konkretem: ma lokalizację w kodzie, ocenę istotności wyrażoną w skali CVSS i opis klasy błędu w słowniku CWE. Kategoria jest pytaniem o mechanizm. Dlatego raport z narzędzia skanującego, który pokazuje listę znalezionych podatności, nie odpowiada na pytanie, czy aplikacja radzi sobie z daną kategorią ryzyka — odpowiada tylko na pytanie, czy narzędzie znalazło przykłady.
To rozróżnienie decyduje o kształcie rozmowy z dostawcą audytu. Zakres opisany jako „sprawdzenie zgodności z OWASP” jest nieweryfikowalny. Zakres opisany jako „przegląd kontroli dostępu w interfejsie API, weryfikacja zarządzania sesją i analiza zależności” ma granicę i daje się odebrać.
Dlaczego skaner nie wystarczy
Narzędzia statyczne i dynamiczne mają rozłączne mocne strony. Analiza statyczna widzi wzorce w kodzie, w tym miejsca, do których test nie dotarł, ale nie wie, które z nich są osiągalne w działającej aplikacji. Analiza dynamiczna pracuje na uruchomionej usłudze, więc widzi realne zachowanie, lecz nie dociera do funkcji ukrytych za logiką uprawnień. Analiza składu zależności wykrywa komponenty z publicznie znanymi podatnościami, których żadne z poprzednich narzędzi nie oceni poprawnie.
Przewodnik testowania owasp.org układa te czynności w kolejność i opisuje, co w każdym kroku stanowi dowód. Z punktu widzenia zespołu istotny jest wniosek odwrotny do intuicji: najtrudniejsze do automatyzacji kategorie dotyczą logiki biznesowej i uprawnień, czyli tego, czego narzędzie nie zna. Tam dowodem jest przegląd prowadzony przez człowieka z dostępem do wymagań.
Pozostaje kwestia regresji. Kategoria raz zamknięta otwiera się ponownie przy każdej zmianie modelu uprawnień albo dodaniu nowej roli. Dlatego pojedynczy audyt potwierdza stan z dnia badania, a nie właściwość aplikacji.
Kolejność wdrożenia, która nie zaczyna się od końca
Zespoły zwykle zaczynają od zakupu narzędzia, a to jest krok dalszy, nie pierwszy. Kolejność, która działa, wygląda inaczej:
- Model uprawnień zapisany poza kodem — kto ma dostęp do czego i na jakiej podstawie. Bez tego dokumentu nie da się stwierdzić, czy kontrola dostępu jest złamana, bo nie ma punktu odniesienia.
- Rejestr zależności i ich wersji — żeby pytanie o komponent z publicznie znaną podatnością miało adresata i termin.
- Automatyzacja w potoku wydania — skanowanie kodu i zależności przy każdej zmianie, z progiem, który blokuje wydanie.
- Przegląd ludzki dla logiki biznesowej — cyklicznie i po każdej zmianie reguł dostępu.
Dokument csrc.nist.gov o nazwie SP 800-218 opisuje ten układ jako praktyki wytwarzania: przygotowanie organizacji, ochrona kodu, wytwarzanie dobrze zabezpieczonego oprogramowania i reagowanie na podatności. Nazwy praktyk są przydatne w rozmowie z zarządem, bo przenoszą dyskusję z narzędzi na proces, który ktoś musi posiadać.
Gdzie w procesie wpisać testy
Test bezpieczeństwa wpisany wyłącznie przed wydaniem produkcyjnym jest testem akceptacyjnym i prawie zawsze przychodzi za późno, żeby cokolwiek przeprojektować. Wpisany wyłącznie w potok automatyczny — pilnuje regresji, ale nie wykryje braku kontroli, której nigdy nie zaprojektowano.
Układ, który sprawdza się w zespołach wytwórczych, rozkłada czynności na osobne momenty: modelowanie zagrożeń przy projektowaniu nowej funkcji, automatyczne skanowanie przy każdym scaleniu zmian oraz przegląd uprawnień przy zmianie roli lub integracji. Pierwszy moment jest najtańszy i najczęściej pomijany, bo nie generuje raportu — generuje decyzję projektową.
Warto też przypisać właścicielstwo. Inżynier bezpieczeństwa aplikacji prowadzi metodę i kwestionuje wyniki, natomiast decyzję o wydaniu z niezamkniętą podatnością podejmuje właściciel produktu. Rozdzielenie tych funkcji jest tym, co zamienia raport w decyzję.
Czytaj także
- Bezpieczeństwo aplikacji webowych: dogłębny przewodnik po OWASP Top 10 dla liderów IT — omówienie kategoria po kategorii, przydatne przy budowie zakresu audytu
- Pentest — co to jest? Metodologia, narzędzia i koszt — co dostajesz, zlecając test z zewnątrz, i jak czytać raport
- Threat hunting — proaktywne wykrywanie zagrożeń — co zrobić z tym, czego skan i przegląd kodu nie pokazały: szukanie śladów w już działającej aplikacji
Rozwijaj kompetencje
Temat rozwijają szkolenia OWASP — kompleksowe testowanie bezpieczeństwa aplikacji webowych oraz OWASP Top 10 — kluczowe zagrożenia bezpieczeństwa aplikacji. Pierwsze jest warsztatem testowym, drugie przeglądem kategorii dla zespołu wytwórczego. Skontaktuj się z nami, żeby dopasować zakres do stosu technologicznego Twojego zespołu.
Najczęściej zadawane pytania (FAQ)
Czy lista OWASP jest zestawem podatności do przetestowania?
Nie. Są to kategorie ryzyka, z których każda obejmuje wiele różnych błędów implementacyjnych. Testowaniu podlegają konkretne mechanizmy aplikacji — kontrola dostępu, zarządzanie sesją, walidacja wejścia, obsługa zależności — a kategoria służy do sprawdzenia, czy przegląd o żadnym z nich nie zapomniał.
Czym różni się audyt bezpieczeństwa aplikacji od skanowania podatności?
Zakresem dowodu. Skanowanie jest czynnością narzędziową i daje listę znalezisk z lokalizacją w kodzie lub w żądaniu. Audyt obejmuje także mechanizmy, których narzędzie nie ocenia: model uprawnień, logikę biznesową, przepływ danych między integracjami. Skanowanie bywa częścią audytu, lecz go nie zastępuje.
Która edycja listy jest aktualna i czy numeracja kategorii się zmienia?
Identyfikator kategorii nosi rok edycji, więc bieżąca lista owasp.org operuje oznaczeniami w postaci A01:2025, a poprzednia — A01:2021. Numeracja i treść kategorii zmieniają się między edycjami, dlatego zakres audytu powinien wskazywać konkretną edycję, aby raport pozostał porównywalny w czasie.
Od czego zacząć testowanie aplikacji webowej we własnym zespole?
Od modelu uprawnień i rejestru zależności, bo bez nich wyniki nie mają punktu odniesienia. Potem wchodzi automatyzacja w potoku wydania, a dopiero na końcu zlecenie testu z zewnątrz — zewnętrzny zespół wyceni wyżej pracę, którą musi wykonać za Ciebie na etapie rozpoznania.