OWASP Top 10: najczęstsze podatności aplikacji web

OWASP Top 10 to najbardziej rozpoznawalne zestawienie ryzyk w aplikacjach webowych — świadoma lista tego, co najczęściej idzie nie tak. Nie jest to checklist do „odhaczenia”, lecz mapa obszarów, które w testach penetracyjnych zwracają najwięcej trafień. Oto najważniejsze z nich, bez żargonu.

Błędna kontrola dostępu — numer jeden

Na czele aktualnej listy stoi Broken Access Control. To nie przypadek — najczęstszym realnym problemem nie jest egzotyczny exploit, lecz brak sprawdzenia, czy dany użytkownik ma prawo zrobić to, o co prosi. Dostęp do cudzych danych przez zmianę identyfikatora, wywołanie funkcji administracyjnej „z ręki”, ominięcie ograniczeń po stronie klienta — to codzienność testów.

Zasada obrony: autoryzuj po stronie serwera, dla każdej operacji, domyślnie odmawiaj.

Injection i błędy kryptografii

Injection (SQL, komendy, LDAP…) — dane od użytkownika trafiają do interpretera jako część polecenia. Obrona to zapytania parametryzowane i traktowanie każdego wejścia jako niezaufanego.
Cryptographic Failures — dane wrażliwe bez szyfrowania, słabe algorytmy, hasła bez odpowiedniego haszowania. Szyfruj w tranzycie i w spoczynku, używaj sprawdzonych bibliotek.

XSS, SSRF i błędna konfiguracja

Cross-Site Scripting (XSS) — wstrzyknięty skrypt wykonuje się w przeglądarce ofiary. Broni kodowanie wyjścia w kontekście i polityka CSP.
SSRF — aplikacja pobiera adres URL podany przez użytkownika i odpytuje zasoby wewnętrzne (np. metadane chmury). Ogranicz, dokąd serwer może się łączyć.
Security Misconfiguration — domyślne hasła, zbędne usługi, gadatliwe błędy. To ta sama dyscyplina, o której piszemy przy bezpieczeństwie chmury.

Jak to wykorzystać w praktyce

OWASP Top 10 najlepiej działa nie jako lista kontrolna, lecz jako wspólny język między deweloperami a bezpieczeństwem i jako punkt wyjścia do modelowania zagrożeń. Wpleciony w cykl wytwarzania (przegląd kodu, testy, bramki w CI/CD) obniża koszt naprawy — bo najtaniej usuwa się podatność, zanim trafi na produkcję. Jeśli chcesz sprawdzić swoją aplikację pod kątem tych ryzyk, umów test penetracyjny.

OWASP Top 10 nie jest pełnym standardem testów

Edycja OWASP Top 10 2021 jest dokumentem świadomościowym opisującym szerokie klasy ryzyka. Nie oznacza, że aplikacja jest bezpieczna po wykonaniu dziesięciu testów. Jedna kategoria, taka jak Broken Access Control, obejmuje wiele różnych błędów: IDOR, brak kontroli funkcji administracyjnej, modyfikację tokenu, dostęp między tenantami i błędy CORS.

Do budowania wymagań użyj OWASP ASVS, a Top 10 pozostaw jako mapę rozmowy z właścicielem produktu. Test powinien wynikać z architektury, przepływów danych, ról i funkcji biznesowych, nie tylko z nazwy kategorii.

Metodyka od wymagania do dowodu

Najpierw zidentyfikuj aktywa i granice zaufania. Dla każdej funkcji określ kto może ją wywołać, na jakim obiekcie i w jakim stanie. Następnie utwórz przypadki pozytywne oraz negatywne: inna rola, inny właściciel, brak parametru, zmieniony typ, powtórzone żądanie i nieoczekiwana kolejność.

Wynik skanera jest hipotezą. Finding powstaje dopiero po ręcznej walidacji, z dowodem wpływu i warunkiem naprawy. Raport powinien opisać przyczynę, a nie tylko payload. Dzięki temu zespół może usunąć całą klasę błędów zamiast łatać jeden endpoint.

Minimalny program AppSec

threat modelling przed implementacją funkcji wysokiego ryzyka;
przegląd kodu dla autoryzacji, kryptografii i granic parserów;
testy jednostkowe i integracyjne dla negatywnych przypadków dostępu;
SAST, SCA i secret scanning jako sygnały wspierające, nie jedyny werdykt;
DAST i test manualny na środowisku reprezentującym produkcję;
retest po naprawie oraz regresja dodana do CI.

Warto połączyć ten proces z OWASP ASVS i bezpieczeństwem API, bo współczesna aplikacja webowa zwykle nie kończy się na interfejsie HTML.

Źródła: OWASP Top 10:2021, OWASP Application Security Verification Standard.