OWASP Top 10:2025 w praktyce - co zmieniło się względem 2021

W skrócie: OWASP Top 10 doczekał się pierwszej aktualizacji od 2021 roku. Wersję 2025 ogłoszono w listopadzie 2025, a finalnie opublikowano w styczniu 2026.

Najważniejsze zmiany: dwie nowe kategorie (łańcuch dostaw oprogramowania oraz obsługa sytuacji wyjątkowych), SSRF przestał być osobną pozycją i został wchłonięty przez kontrolę dostępu, a błędna konfiguracja awansowała na drugie miejsce.

Jeśli w Waszej dokumentacji, umowach albo odpowiedziach na ankiety bezpieczeństwa pojawia się odwołanie do OWASP Top 10, warto sprawdzić, do której edycji. Numeracja kategorii się zmieniła i A03 znaczy dziś co innego niż rok temu.

Co się zmieniło względem 2021

Zmiana	Na czym polega
Dwie nowe kategorie	Software Supply Chain Failures (A03) oraz Mishandling of Exceptional Conditions (A10).
SSRF znika z listy	Nie dlatego, że przestał być groźny - został wchłonięty przez Broken Access Control.
Błędna konfiguracja w górę	Z A05 na A02. Jedna z najczęstszych realnych przyczyn incydentów.
Injection w dół	Z A03 na A05. Nowoczesne frameworki domyślnie utrudniają klasyczne wstrzyknięcia.
Zmiany nazw	M.in. Authentication Failures (A07) i Security Logging and Alerting Failures (A09).

Podstawa danych też urosła: nowa edycja opiera się na analizie ponad 175 tysięcy rekordów CVE i konsultacjach ze specjalistami z całego świata.

A01:2025 Broken Access Control

Drugą edycję z rzędu na pierwszym miejscu, a teraz jeszcze szersza, bo obejmuje SSRF.

Jak wygląda: klient otwiera /faktury/1042, zmienia numer na 1041 i widzi cudzą fakturę. Albo funkcja "pobierz obrazek z adresu URL", w której zamiast obrazka podaje się adres usługi wewnętrznej lub punktu metadanych chmury - to właśnie dawne SSRF, dziś traktowane jako obejście kontroli dostępu do zasobów.

Co zrobić: sprawdzać uprawnienia po stronie serwera przy każdym żądaniu, domyślnie odmawiać, testować z dwoma kontami w tej samej roli, a przy pobieraniu zasobów z zewnątrz stosować listę dozwolonych adresów zamiast listy zakazanych.

A02:2025 Security Misconfiguration

Awans z piątego miejsca. Aplikacja napisana poprawnie, ale uruchomiona nieostrożnie.

Jak wygląda: domyślne hasła, tryb debugowania na produkcji, katalog z listingiem plików, panel bazy danych dostępny z internetu, wystawione kopie zapasowe, komunikaty błędów zdradzające ścieżki i wersje.

Co zrobić: powtarzalny proces wdrożenia zamiast ręcznej konfiguracji, wyłączanie tego, co niepotrzebne, i regularny przegląd tego, co faktycznie widać z zewnątrz.

A03:2025 Software Supply Chain Failures

Nowa kategoria i od razu na podium. Rozszerza dawne "podatne i nieaktualne komponenty" o cały łańcuch: zależności, narzędzia budowania, rejestry pakietów, obrazy kontenerów, wtyczki do środowisk deweloperskich.

Jak wygląda: framework sprzed czterech lat z publicznie znanymi podatnościami. Przejęty pakiet npm, który po aktualizacji zaczyna wykradać zmienne środowiskowe. Skompromitowany proces budowania wstrzykujący kod do artefaktu, mimo że repozytorium jest czyste.

Co zrobić: mieć listę używanych komponentów i wersji, przypinać wersje zamiast pobierać "najnowsze", weryfikować podpisy artefaktów i traktować proces budowania jak system produkcyjny - bo kto ma do niego dostęp, ma dostęp do produkcji.

A04:2025 Cryptographic Failures

Ochrona danych wrażliwych w spoczynku i w tranzycie.

Jak wygląda: hasła jako MD5 albo jawnie, brak szyfrowania danych osobowych, HTTP w części serwisu, przestarzałe wersje TLS, klucze zaszyte w kodzie i wypchnięte do repozytorium.

Co zrobić: hasła haszować algorytmem przeznaczonym do haseł (bcrypt, argon2), wymuszać HTTPS wszędzie, sekrety trzymać poza kodem i wiedzieć, gdzie w ogóle leżą dane wrażliwe.

A05:2025 Injection

Spadek z trzeciego miejsca, ale nie zniknięcie. Dane od użytkownika trafiają do interpretera i zmieniają sens polecenia.

Jak wygląda: SQL injection w wyszukiwarce, wstrzyknięcie polecenia systemowego przez parametr generujący PDF, XSS w polu komentarza wykonujący skrypt u innego użytkownika.

Co zrobić: zapytania parametryzowane zamiast sklejania SQL, walidacja po stronie serwera, kodowanie danych przy wyświetlaniu odpowiednio do kontekstu.

A06:2025 Insecure Design

Błąd w samym pomyśle, nie w implementacji - dlatego nie da się go załatać poprawką.

Jak wygląda: reset hasła oparty na nazwisku panieńskim matki. Proces zamówienia, w którym cenę przesyła przeglądarka, a serwer jej nie weryfikuje. Brak limitu prób przy kodzie SMS, przez co sześć cyfr da się odgadnąć siłowo.

Co zrobić: rozważać zagrożenia na etapie projektu i pytać "jak ktoś mógłby to wykorzystać" przy każdej funkcji dotykającej pieniędzy, danych albo uprawnień.

A07:2025 Authentication Failures

Nazwa skrócona względem 2021. Wszystko wokół logowania i sesji.

Jak wygląda: brak ograniczenia prób logowania, sesja niewygasająca miesiącami, identyfikator sesji niezmieniany po zalogowaniu, reset hasła zdradzający istnienie konta, brak drugiego składnika na kontach administracyjnych.

Co zrobić: ograniczać nieudane próby, wymuszać uwierzytelnianie wieloskładnikowe przynajmniej dla kont uprzywilejowanych, unieważniać sesje przy wylogowaniu i zmianie hasła.

A08:2025 Software or Data Integrity Failures

Zaufanie do czegoś, czego nie zweryfikowano.

Jak wygląda: aktualizacja pobierana bez sprawdzenia podpisu, skrypt dołączany z cudzego serwera bez kontroli zawartości, zserializowane dane sesji przyjmowane od klienta bez weryfikacji.

Co zrobić: weryfikować podpisy i sumy kontrolne, przypinać wersje, zabezpieczyć proces wdrożeniowy.

A09:2025 Security Logging and Alerting Failures

Zmiana nazwy z "monitoring" na "alerting" jest znacząca: chodzi nie o samo zbieranie logów, tylko o to, czy ktokolwiek na nie reaguje.

Jak wygląda: brak logów z prób logowania, logi kasowane po tygodniu, brak alertu przy tysiącu nieudanych prób w minutę, alerty lecące na skrzynkę, której nikt nie czyta.

Co zrobić: logować zdarzenia istotne dla bezpieczeństwa, trzymać logi poza atakowanym systemem, ustawić alerty na to, co wymaga reakcji, i sprawdzić, czy ktoś rzeczywiście reaguje.

A10:2025 Mishandling of Exceptional Conditions

Druga nowa kategoria. Dotyczy tego, jak aplikacja zachowuje się, gdy coś pójdzie nie tak - a to często moment, w którym zabezpieczenia przestają działać.

Jak wygląda: błąd bazy danych powodujący, że funkcja sprawdzająca uprawnienia zwraca wartość domyślną i przepuszcza żądanie. Wyjątek połykany pustym blokiem, przez co nieudana weryfikacja płatności wygląda jak udana. Komunikat błędu ujawniający zapytanie SQL i strukturę bazy.

Co zrobić: projektować tak, żeby błąd kończył się odmową, a nie przepuszczeniem. Nie połykać wyjątków po cichu. Rozdzielić komunikat dla użytkownika od wpisu w logu - szczegóły do logu, użytkownikowi ogólna informacja.

Czego OWASP Top 10 nie obejmuje

Ważne przy odpowiadaniu na ankiety bezpieczeństwa: to nie jest pełna lista podatności, tylko zestaw najczęstszych kategorii. "Zgodność z OWASP Top 10" nie jest certyfikacją i nikt jej formalnie nie wydaje.

Poza listą zostaje przede wszystkim logika biznesowa. Możliwość zamówienia towaru za ujemną kwotę, ominięcia kroku płatności przez cofnięcie się w procesie, wielokrotnego użycia kodu rabatowego. Żaden skaner tego nie znajdzie, bo technicznie aplikacja działa dokładnie tak, jak ją napisano. To ta część, w której test manualny daje wartość nieosiągalną automatem.

Osobna sprawa to aplikacje oparte na modelach językowych - mają własną listę, OWASP Top 10 for LLM Applications, bo klasyczna lista nie opisuje ani wstrzykiwania promptu, ani nadmiernych uprawnień agenta.

Od czego zacząć

Przy ograniczonym czasie: A01 i A02. Kontrola dostępu i błędna konfiguracja to statystycznie najczęstsze źródła realnych problemów, a jednocześnie obszary, gdzie stosunkowo łatwo o szybką poprawę.

Potem A03, bo uporządkowanie łańcucha dostaw to głównie kwestia procesu, i A07, bo błędy w logowaniu dotykają wszystkich użytkowników naraz.

Zobacz też, jak przygotować firmę do testu penetracyjnego.