OWASP Top 10:2025 okiem testera: co sprawdzić w każdej z dziesięciu kategorii

Jeśli wasza checklista testów bezpieczeństwa powstała przed 2026 rokiem, sprawdza już nieaktualną listę. OWASP ogłosił nową edycję Top 10 w listopadzie 2025 roku, a sfinalizował ją w styczniu 2026. Doszły dwie zupełnie nowe kategorie, jedna znana pozycja zniknęła jako osobny punkt, a jedna wskoczyła z piątego miejsca na drugie. Ten artykuł przechodzi przez wszystkie dziesięć kategorii z perspektywy osoby, która ma je realnie sprawdzić, i odpowiada na pytanie, które w praktyce jest ważniejsze niż sama lista: co złapiecie zwykłymi testami, co wymaga narzędzia w potoku CI, a czego nie wykryje żaden skaner.

Co zmieniło się między edycją 2021 a 2025

Zacznijmy od metodyki, bo ona tłumaczy, dlaczego zmiany nie są kosmetyczne. Ósma edycja Top 10 powstała na danych z ponad 2,8 miliona aplikacji, obejmuje 248 kategorii słabości CWE i pochodzi od trzynastu organizacji dostarczających dane, między innymi Veracode, Contrast Security, Bugcrowd, Semgrep i Sonar.

Najważniejsza zmiana merytoryczna to przesunięcie akcentu z objawów na przyczyny. Widać to w trzech decyzjach. Po pierwsze, Server Side Request Forgery przestał być osobną kategorią i został wchłonięty przez Broken Access Control, bo to w istocie problem kontroli dostępu, nie osobna klasa błędu. Po drugie, dawna kategoria podatnych i nieaktualnych komponentów urosła do pełnoprawnego Software Supply Chain Failures, obejmującego cały łańcuch dostaw oprogramowania, nie tylko wersje bibliotek. Po trzecie, doszła kategoria Mishandling of Exceptional Conditions, czyli błędna obsługa sytuacji wyjątkowych, wskazana przez praktyków, a nie przez statystykę.

Dla zespołu testowego oznacza to jedno: dwie nowe kategorie to dwa obszary, których wasze dotychczasowe scenariusze prawdopodobnie w ogóle nie dotykają. Reszta listy to głównie zmiana kolejności, ale kolejność też coś mówi. Security Misconfiguration awansowała z piątego miejsca na drugie, a Cryptographic Failures i Injection spadły, co nie znaczy, że zniknęły, tylko że branża nauczyła się je ograniczać narzędziami, a konfiguracja rozjeżdża się szybciej, niż ktokolwiek zdąży ją sprawdzić.

Dziesięć kategorii i to, co przy każdej robi tester

Cztery kategorie, które łapiecie zwykłymi testami funkcjonalnymi

Najważniejsza wiadomość dla zespołów bez ofensywnego działu bezpieczeństwa: cztery pozycje z listy, w tym ta na pierwszym miejscu, są w zasięgu zespołu QA, który umie pisać scenariusze testowe. Nie potrzeba do tego ani drogiego narzędzia, ani certyfikatu z testów penetracyjnych, tylko dwóch kont testowych o różnych rolach i konsekwencji.

A01, kontrola dostępu. Zalogujcie się jako użytkownik A, otwórzcie zasób należący do użytkownika B, podmieniając identyfikator w adresie albo w treści żądania. Powtórzcie to samo na poziomie funkcji: wywołajcie z konta zwykłego użytkownika operację dostępną tylko dla administratora, z pominięciem interfejsu. Te dwa wzorce, znane jako naruszenie autoryzacji na poziomie obiektu i na poziomie funkcji, są w edycji 2025 wprost wpisane w opis kategorii, bo w aplikacjach opartych o API to najczęściej wykorzystywane ścieżki ataku.

A07, uwierzytelnianie. Sprawdźcie pełne przepływy, nie sam ekran logowania: co się dzieje po zmianie hasła ze starą sesją, czy token wygasa realnie, czy odzyskiwanie hasła nie ujawnia, które konta istnieją, czy limit nieudanych prób działa także dla API. Raport Verizon Data Breach Investigations Report za 2025 rok pokazuje, dlaczego to nie jest formalność: nadużycie danych logowania odpowiada za 22 procent incydentów, a przy atakach na podstawowe aplikacje webowe aż 88 procent wykorzystywało skradzione dane logowania.

A10, sytuacje wyjątkowe. Nowa kategoria, a scenariusze stare jak testowanie: co robi aplikacja, gdy zależność nie odpowiada, gdy transakcja przerwie się w połowie, gdy przyjdzie żądanie większe niż limit. Pytanie kluczowe brzmi: czy system przy błędzie zamyka się bezpiecznie, czy otwiera. Aplikacja, która przy awarii usługi autoryzacyjnej przepuszcza żądanie dalej, właśnie zamieniła awarię w lukę. Do tego dochodzi treść komunikatu błędu, bo ślad stosu na produkcji to gotowa mapa systemu dla atakującego.

A02, konfiguracja, jest tu przypadkiem mieszanym. Część rzeczy sprawdzicie ręcznie w kilka minut: domyślne konta, dostępne panele administracyjne, komunikaty diagnostyczne, nagłówki bezpieczeństwa w odpowiedzi. Reszta wymaga automatu, bo konfiguracja zmienia się przy każdym wdrożeniu, a jednorazowy przegląd starzeje się tego samego dnia. To zresztą powód awansu tej kategorii na drugie miejsce: nie dlatego, że nagle staliśmy się gorsi w konfigurowaniu, tylko dlatego, że wdrażamy częściej, niż sprawdzamy. Branża ma na to własną wersję prawa Murphy’ego: panel administracyjny z domyślnym hasłem zawsze znajdzie się w tej jednej aplikacji, którą każdy uważał za sprawdzoną przez kogoś innego.

Trzy kategorie, w których pracę wykonuje narzędzie w potoku

Przy A03, A05 i A04 ręczne testowanie jest najmniej efektywną drogą. Tu wygrywa automat wpięty w potok, bo problem polega na skali i na tempie zmian, nie na sprycie scenariusza.

A03, łańcuch dostaw, to nowa kategoria z najwyższym wskaźnikiem występowania w danych tej edycji, a jednocześnie najsłabiej pokryta zgłoszeniami podatności, co jest niepokojącym połączeniem: dzieje się dużo, mierzymy mało. Minimum, które da się wdrożyć w jeden sprint, to spis komponentów aplikacji, automatyczna kontrola wersji zależności przy każdej zmianie i reguła, że artefakt wchodzi na produkcję tylko z zaufanego, podpisanego źródła. Dane Verizona pokazują, że udział stron trzecich w naruszeniach podwoił się do 30 procent, a wykorzystanie znanych podatności wzrosło rok do roku o 34 procent, więc to jest dokładnie ten obszar, w którym opóźnienie kosztuje najszybciej.

A05, wstrzyknięcia, spadły na piąte miejsce dzięki frameworkom i zapytaniom parametryzowanym, ale spadek dotyczy głównie interfejsu użytkownika. Parametry API, nagłówki i pola, których nie widać w przeglądarce, są testowane rzadziej, bo nie ma ich w ścieżce klikanej przez człowieka. Jeśli macie testy API w regresji, dołożenie do nich zestawu danych brzegowych jest tańsze niż osobny projekt bezpieczeństwa. Opisaliśmy szerzej, jak rozkłada się rola testowania manualnego i automatycznego w bezpieczeństwie.

A04, kryptografia, jest kategorią, w której tester rzadko ocenia algorytm, a często wyłapuje sytuację, w której dane wrażliwe wychodzą tam, gdzie nie powinny: do logów, do adresu URL, do komunikatu błędu, do zewnętrznego narzędzia analitycznego. To zadanie dla przeglądu ruchu sieciowego i logów podczas normalnych testów funkcjonalnych, nie dla osobnego audytu. W sektorze regulowanym ta kategoria bywa dodatkowo objęta wymaganiami nadzorczymi, więc jej wynik trzeba umieć udokumentować, nie tylko naprawić.

Trzy kategorie, których żaden skaner za was nie sprawdzi

A06, A08 i A09 mają wspólną cechę: dotyczą decyzji i procesów, nie pojedynczych linii kodu. Skaner nie ma jak ich ocenić, bo z jego perspektywy wszystko działa zgodnie z implementacją. Problem polega na tym, że implementacja jest zgodna z błędnym założeniem.

Przy A06, projektowaniu, narzędziem testera jest scenariusz nadużycia, czyli odwrócone wymaganie: zamiast pytać, czy użytkownik może kupić bilet, pytamy, czy może kupić go za złotówkę, tysiąc razy na sekundę albo po cudzej cenie. Większość takich luk powstaje, gdy reguła biznesowa jest pilnowana tylko po stronie interfejsu. Jeśli sprawdzicie ją, wysyłając żądanie z pominięciem tego interfejsu, dostaniecie odpowiedź w kilka minut.

Przy A08, integralności, pytanie brzmi, czy system ufa czemuś, czego nie zweryfikował: aktualizacji z niepodpisanego źródła, obiektowi odtworzonemu z danych przesłanych przez użytkownika, konfiguracji pobranej z zewnątrz. Edycja 2025 wyraźnie rozdziela tę kategorię od łańcucha dostaw: A03 dotyczy tego, skąd wzięliście komponent, A08 tego, czy sprawdzacie, co dzieje się z nim i z danymi w trakcie działania.

A09 zmienił nazwę w sposób, który warto zauważyć: dawne monitorowanie zastąpiło alarmowanie. To nie jest zmiana słowa, tylko postawienie sprawy uczciwie. Log, na który nikt nie reaguje, nie jest wykrywaniem, tylko archiwum. Test jest prosty i nieprzyjemny: wykonajcie serię nieudanych logowań albo próbę dostępu do cudzego zasobu i sprawdźcie dwie rzeczy. Czy w logach jest ślad. I czy ktokolwiek się o tym dowiedział.

Jak wpiąć to w regresję, nie zatrzymując wydań

Najczęstszy błąd przy wdrażaniu Top 10 to próba zrobienia wszystkiego naraz i w jednym trybie. Lista dzieli się naturalnie na trzy rytmy, a rozdzielenie ich decyduje o tym, czy bezpieczeństwo mieści się w normalnym cyklu wydawniczym, czy staje się wąskim gardłem.

Z naszego doświadczenia ze szkoleń zamkniętych z testów bezpieczeństwa, takich jak dwudniowe warsztaty dla czternastoosobowego zespołu AgroApp w czerwcu 2026, wynika jedna powtarzalna obserwacja: zespoły QA wykonują już sporą część tej pracy, tylko nikt jej nie nazywa testem bezpieczeństwa. Rozpisanie dziesięciu kategorii na trzy rytmy zwykle bardziej porządkuje to, co już robicie, niż dokłada nowe obowiązki.

Kolejność ma znaczenie także finansowo. Test penetracyjny zamówiony na aplikacji, w której nikt nie sprawdził kontroli dostępu ani konfiguracji, zwróci wam listę rzeczy, które zespół mógł znaleźć sam, i to za znacznie wyższą stawkę. Różnicę między jednym a drugim rozstrzygnęliśmy w osobnym tekście o tym, czym różnią się testy penetracyjne od testów bezpieczeństwa, i to rozróżnienie jest przy planowaniu budżetu ważniejsze niż sama lista OWASP.

Nasza perspektywa

W Quality Island testy bezpieczeństwa są jedną z podstawowych linii usługowych, obok testów funkcjonalnych, regresyjnych, wydajnościowych i dostępności, a szkolenie z testowania bezpieczeństwa należy do najczęściej zamawianych pozycji w naszym katalogu. Z ponad 450 000 testów automatycznych napisanych w projektach dla ponad 100 firm wynika obserwacja, która przy tej liście wraca regularnie.

Pierwsza: najdroższe luki rzadko są najbardziej wyrafinowane. Cztery kategorie opisane wyżej jako możliwe do sprawdzenia zwykłymi scenariuszami odpowiadają za dużą część realnych incydentów, a nie wymagają ani nowego narzędzia, ani nowego etatu. Zespół, który dopisze do regresji dwadzieścia przypadków na kontrolę dostępu i uwierzytelnianie, zrobi dla bezpieczeństwa więcej niż zespół, który przez kwartał wybiera platformę.

Druga: lista OWASP działa jako mapa, nie jako plan testów. Przepisanie dziesięciu nazw do arkusza i odhaczenie ich raz w roku daje poczucie kontroli bez jej treści. Wartość pojawia się dopiero wtedy, gdy każda kategoria dostaje właściciela, rytm i konkretny przypadek testowy, czyli gdy trafia do tego samego procesu, w którym testujecie funkcje. O tym, ile kosztuje pominięcie tego kroku, pisaliśmy na Strefie QA w tekście ile kosztuje luka bezpieczeństwa, której nikt nie szukał.

Trzecia, istotna dla firm pod nadzorem: od 2026 roku coraz częściej trzeba nie tylko testować, ale też wykazać, że się testowało. Wymogi dotyczące testowania podatności przez cały cykl życia produktu, o których piszemy osobno przy Cyber Resilience Act, wymagania NIS2 wobec dostawców oprogramowania, które sprawdzamy w ramach testów bezpieczeństwa dostawców, oraz obowiązki sektora finansowego sprawiają, że raport z testu bezpieczeństwa staje się dokumentem, nie notatką. Warto ustawić to raz porządnie, zanim zapyta o to ktoś z zewnątrz.

Powiązane na blogu Quality Island

• Testy penetracyjne a testy bezpieczeństwa: czym się różnią
• Testowanie bezpieczeństwa: rola testowania manualnego i automatycznego
• Szkolenia z cyberbezpieczeństwa i testowania bezpieczeństwa

Pełna lista źródeł

• OWASP, Top 10:2025, wprowadzenie i metodyka: ponad 2,8 mln aplikacji, 248 kategorii CWE, trzynaście organizacji dostarczających dane
• OWASP, OWASP Top 10:2025, pełna lista dziesięciu kategorii z opisami i powiązanymi CWE
• MITRE, Common Weakness Enumeration, słownik kategorii słabości oprogramowania, z którego pochodzą 248 kategorii CWE analizowanych w Top 10:2025
• Verizon, 2025 Data Breach Investigations Report: udział skradzionych danych logowania i wykorzystania podatności w incydentach
• Quality Island, dane firmowe: ponad 450 000 napisanych testów automatycznych, ponad 100 firm korzystających z usług lub szkoleń