Omówienie OWASP Top 10 2025
Wcześniejsza wersja tej strony pokazywała listę z edycji 2021 opisaną jako „2025 (przykładowa)". Poniżej jest oficjalna lista OWASP Top 10:2025 z danymi ze wstępu do edycji. Rozdziały w części „Testowanie podatności" są ułożone według edycji 2025; doszedł rozdział o nowej kategorii A10.
Czym jest OWASP Top 10?
OWASP (Open Worldwide Application Security Project) to globalna inicjatywa non-profit zajmująca się poprawą bezpieczeństwa oprogramowania.
Lista OWASP Top 10 to dokument budujący świadomość najpoważniejszych ryzyk w aplikacjach webowych. Edycja 2025 jest ósmą. Powstała na podstawie:
- danych o ponad 2,8 mln aplikacji przekazanych przez organizacje testujące,
- ankiety wśród praktyków — dwie kategorie trafiły na listę z jej wyników, bo dane z testów z natury opisują przeszłość i nie obejmują ryzyk, których nie da się jeszcze testować automatycznie.
Liczba analizowanych słabości (CWE) rośnie z edycji na edycję: ok. 30 w 2017, prawie 400 w 2021, 589 w 2025.
🔟 OWASP Top 10:2025
| ID | Nazwa | Co się zmieniło względem 2021 |
|---|---|---|
| A01:2025 | Broken Access Control | nadal #1; wchłonął SSRF (dawne A10:2021) |
| A02:2025 | Security Misconfiguration | awans z #5 |
| A03:2025 | Software Supply Chain Failures | nowa — rozszerzenie A06:2021 Vulnerable and Outdated Components |
| A04:2025 | Cryptographic Failures | spadek z #2 |
| A05:2025 | Injection | spadek z #3; obejmuje też XSS |
| A06:2025 | Insecure Design | spadek z #4 |
| A07:2025 | Authentication Failures | bez zmian pozycji; dawniej „Identification and Authentication Failures" |
| A08:2025 | Software or Data Integrity Failures | bez zmian pozycji |
| A09:2025 | Security Logging and Alerting Failures | bez zmian pozycji; dawniej „…Logging and Monitoring Failures" |
| A10:2025 | Mishandling of Exceptional Conditions | nowa |
UWAGA: OWASP Top 10 to nie tylko lista, ale też punkt odniesienia do testowania, raportowania, audytów i edukacji. Nie jest za to standardem wymagań — do tego służy OWASP ASVS.
Co się zmienia w 2025?
Edycja ma dwie nowe kategorie i jedno połączenie. Liczby i uzasadnienia pochodzą ze wstępu OWASP, chyba że zaznaczono inaczej:
- SSRF w Broken Access Control. Autorzy nie uzasadniają połączenia we wstępie; logika jest jednak prosta — żądanie wykonane przez serwer w imieniu użytkownika sięga tam, dokąd serwer ma dostęp, a użytkownik nie powinien. Kategoria liczy teraz 40 CWE; co najmniej jedną z nich miało średnio 3,73% testowanych aplikacji.
- Security Misconfiguration na #2. 3,00% aplikacji z co najmniej jedną z 16 CWE. Autorzy wiążą wzrost z tym, że coraz większa część zachowania aplikacji wynika z konfiguracji, a nie z kodu.
- Software Supply Chain Failures (nowa). Obejmuje już nie tylko przestarzałe biblioteki, ale całe zaplecze: zależności, systemy budowania i dystrybucję. Ma tylko 5 CWE i najmniej wystąpień w danych, ale najwyższe średnie oceny exploitowalności i wpływu z CVE. Społeczność w ankiecie zdecydowanie wskazała ją jako główną obawę — autorzy uważają, że mała liczba trafień wynika z trudności w testowaniu, a nie z rzadkości problemu.
- Cryptographic Failures, Injection, Insecure Design niżej. To nie znaczy, że problem zniknął: kryptografia ma 3,80% aplikacji z co najmniej jedną z 32 CWE, a Injection — najwięcej powiązanych CVE ze wszystkich kategorii. Pozycja na liście nie wynika więc wyłącznie z częstości występowania (3,80% to więcej niż 3,73% dla A01, a mimo to #4). Insecure Design spadł, bo wyprzedziły go A02 i A03; autorzy odnotowują też wyraźną poprawę w modelowaniu zagrożeń.
- Authentication Failures — według autorów standardowe frameworki uwierzytelniania wydają się zmniejszać liczbę wystąpień.
- Logging and Alerting — zmiana nazwy podkreśla, że logi bez alertów mają minimalną wartość przy wykrywaniu incydentów.
- Mishandling of Exceptional Conditions (nowa). 24 CWE: niewłaściwa obsługa błędów, błędy logiczne, failing open (system w razie błędu przepuszcza zamiast blokować) i inne skutki nietypowych stanów, w które aplikacja może wejść.
Mapowanie na rozdziały kursu
Rozdziały kursu powstały pierwotnie według edycji 2021. Jeśli korzystałeś z nich wcześniej, ta tabela pokazuje, gdzie co trafiło (adresy stron się nie zmieniły):
| Kategoria 2025 | Dawniej w kursie (2021) |
|---|---|
| A01 Broken Access Control | A01 Broken Access Control + A10 SSRF |
| A02 Security Misconfiguration | A05 Security Misconfiguration |
| A03 Software Supply Chain Failures | A06 Vulnerable and Outdated Components (rozszerzony) |
| A04 Cryptographic Failures | A02 Cryptographic Failures |
| A05 Injection | A03 Injection |
| A06 Insecure Design | A04 Insecure Design |
| A07 Authentication Failures | A07 Identification and Authentication Failures |
| A08 Software or Data Integrity Failures | A08 Software and Data Integrity Failures |
| A09 Security Logging and Alerting Failures | A09 Security Logging and Monitoring Failures |
| A10 Mishandling of Exceptional Conditions | — (nowy rozdział) |
Jak korzystać z OWASP Top 10?
- Testy bezpieczeństwa – praktyczny plan testów dla pentesterów; szczegółową metodykę daje OWASP WSTG.
- Audyt bezpieczeństwa aplikacji – punkt wyjścia do checklist zgodności.
- Szkolenia zespołów developerskich – uczenie na przykładach z OWASP.
- Tworzenie polityk bezpieczeństwa – mapowanie ryzyk na OWASP Top 10.
Wsparcie narzędziowe
Część narzędzi — np. OWASP ZAP (tagi alertów) czy SonarQube (raporty bezpieczeństwa) — przypisuje wyniki do kategorii OWASP Top 10. Sprawdź, której edycji używa Twoje narzędzie — przy zmianie numeracji A01–A10 łatwo o pomyłkę w raporcie.
📌 Podsumowanie
OWASP Top 10 to punkt wyjścia do zrozumienia realnych zagrożeń bezpieczeństwa, nie tylko "błędów w kodzie". Każdy test, audyt i raport powinien się do niej odnosić — z podaniem edycji, np.
A03:2025.
W kolejnym rozdziale poznasz strukturę kursu i oczekiwane rezultaty – czyli co dokładnie zrobisz, przetestujesz i zraportujesz.