7 listopada 2025 w Aktualności, Bezpieczeństwo
Organizacja OWASP (Open Web Application Security Project) od wielu lat publikuje listę Top 10 najważniejszych ryzyk bezpieczeństwa aplikacji webowych. Stanowi ona punkt odniesienia dla deweloperów, audytorów, operacji DevSecOps oraz działów IT. Wersja OWASP Top 10 2021 została szeroko przyjęta i zaczyna być fundamentem standardów kodowania, testowania, wdrożenia i monitorowania bezpieczeństwa aplikacji.
W związku z dynamicznie zmieniającym się krajobrazem zagrożeń (mikroserwisy, API-first, chmura, CI/CD, model DevSecOps, a także elementy generatywnej sztucznej inteligencji) OWASP przygotowuje wydanie listy na rok 2025 (aktualnie w fazie Release Candidate).
Poniżej przedstawiamy:
- kluczowe zmiany i najważniejsze zagadnienia z OWASP Top 10 2021,
- roboczą listę OWASP Top 10 2025 (RC) – co zmienia i dlaczego,
- porównanie obu list, wraz z rekomendacjami dla zespołów deweloperskich, bezpieczeństwa i operacji IT.
Spis Treści
OWASP Top 10 2021 – przypomnienie
Tabela przedstawia 10 pozycji z wersji 2021:
| Kod | Kategoria | Krótkie wyjaśnienie |
|---|---|---|
| A01:2021 | Broken Access Control | Naruszenie mechanizmów kontroli dostępu – użytkownik wykonuje akcję lub uzyskuje dostęp, na który nie ma uprawnień. |
| A02:2021 | Cryptographic Failures | Błędy w stosowaniu kryptografii (słabe algorytmy, złe klucze, brak ochrony danych w spoczynku/transmisji) – dawniej „Sensitive Data Exposure”. |
| A03:2021 | Injection | Wstrzykiwanie kodu/komend (SQL, OS, LDAP, XSS itp.). W wersji 2021 XSS zostało włączone do tej kategorii. |
| A04:2021 | Insecure Design | Nowa kategoria w 2021 – koncentruje się na błędach już w etapie projektowania aplikacji/architektury, modelowaniu zagrożeń, wzorcach bezpiecznego projektowania. |
| A05:2021 | Security Misconfiguration | Błędy konfiguracyjne np. domyślne hasła, niezamknięte porty, niepoprawne ustawienia serwera/aplikacji. |
| A06:2021 | Vulnerable and Outdated Components | Użycie komponentów/ bibliotek/ frameworków z znanymi lukami lub które nie są wspierane. |
| A07:2021 | Identification and Authentication Failures | Błędy w mechanizmach uwierzytelniania i identyfikacji – słabe hasła, brak MFA, sesje nieprawidłowo zarządzane. |
| A08:2021 | Software and Data Integrity Failures | Naruszenia integralności danych/aplikacji – np. niezweryfikowane aktualizacje, brak weryfikacji kodu w CI/CD. |
| A09:2021 | Security Logging and Monitoring Failures | Brak lub niewłaściwe logowanie, monitoring, co utrudnia wykrycie naruszenia i reakcję na incydent. |
| A10:2021 | Server-Side Request Forgery (SSRF) | Aplikacja wykonuje żądania HTTP/HTTPS w imieniu użytkownika bez odpowiedniej walidacji, co umożliwia dostęp do wewnętrznych zasobów. |
Kluczowe zmiany względem poprzednich edycji:
- „Broken Access Control” wskoczyło na pozycję #1.
- „Insecure Design” i „Software and Data Integrity Failures” zostały dodane jako nowe kategorie.
- Zmiana nazewnictwa: np. „Cryptographic Failures” zamiast „Sensitive Data Exposure”.
- Włączenie XSS do kategorii „Injection”.
Dla zespołów DevSecOps istotne jest, aby lista 2021 nadal stanowiła podstawę odnośników kontrolnych (secure coding guidelines, testów pentestowych, audytów) – ale już teraz należy przygotowywać się na nadchodzące zmiany.
OWASP Top 10 2025 – wersja robocza (Release Candidate)
Choć oficjalna finalna wersja OWASP Top 10 2025 jeszcze nie została opublikowana (stan na wrzesień/październik 2025). Na stronie projektu pojawił się jednak następujący roboczy spis (RC):
| Kod | Kategoria |
|---|---|
| A01:2025 | Broken Access Control |
| A02:2025 | Security Misconfiguration |
| A03:2025 | Software Supply Chain Failures |
| A04:2025 | Cryptographic Failures |
| A05:2025 | Injection |
| A06:2025 | Insecure Design |
| A07:2025 | Authentication Failures |
| A08:2025 | Software or Data Integrity Failures |
| A09:2025 | Logging and Alerting Failures |
| A10:2025 | Mishandling of Exceptional Conditions |
(Źródło: strona projektu OWASP Top Ten 2025 RC1)
Wyjaśnienia i implikacje poszczególnych pozycji
- Broken Access Control (A01) – pozostaje na szczycie; w 2025 nacisk będzie większy na złożone środowiska – micro-serwisy, chmura, federowane tożsamości, zero-trust.
- Security Misconfiguration (A02) – przeniesiona wyżej, co wskazuje, że błędy konfiguracyjne są nadal bardzo częste i groźne w architekturze nowoczesnych aplikacji.
- Software Supply Chain Failures (A03) – nowa lub mocno przedefiniowana kategoria: podkreśla upadek zależności zewnętrznych, pakietów, kontenerów, pipeline’ów CI/CD jako krytycznych wektorów ryzyka.
- Cryptographic Failures (A04) – nadal kluczowa, choć spadek względem 2021 może wynikać z lepszych bibliotek i świadomości, ale wymagania się zaostrzają (np. TLS 1.3, AEAD, post-quantum).
- Injection (A05) – nadal obecna, ale może być mniej „headline’owa” niż wcześniej; jednak rozszerzona o nowe wektory (GraphQL, API, AI modelle).
- Insecure Design (A06) – nadal ważna, choć przesunięta w dół; podkreśla „shift-left” w procesie tworzenia oprogramowania.
- Authentication Failures (A07) – przeniesiona i zmodyfikowana z 2021 („Identification and Authentication Failures”) – uwaga na sesje, tokeny, federację, phishing impersonację.
- Software or Data Integrity Failures (A08) – integracja kodu, ciągłość dostawy, aktualizacje, tamper-proof – jeszcze ważniejsze w epoce DevOps.
- Logging and Alerting Failures (A09) – kategoria rozszerzona z wersji 2021 („Security Logging and Monitoring Failures”) – teraz większy nacisk na alertowanie w czasie rzeczywistym, automatyczne działania, telemetrykę.
- Mishandling of Exceptional Conditions (A10)</b – nowa lub zrebrendowana kategoria: niewłaściwe zarządzanie błędami, wyjątkami, sesjami awaryjnymi, brak przewidywania sytuacji brzegowych.
Porównanie obu list (2021 vs 2025)
Poniżej kluczowe różnice oraz implikacje:
| Aspekt | Co się zmieniło | Dlaczego to istotne dla praktyki |
|---|---|---|
| Priorytet/pozycja | W 2021 „Broken Access Control” było #1; w 2025 nadal #1 – co wskazuje na trwały problem. | Zespoły powinny nadal priorytetyzować autoryzację, ale z uwzględnieniem nowej architektury (API, chmura). |
| Zmiany kategorii | Pojawiła się np. „Software Supply Chain Failures” (#3 w 2025), co nie było explicite w 2021. | Zespoły powinny zwrócić uwagę na łańcuch dostaw (biblioteki, kontenery, pipeline). |
| Rebranding i zakres | „Authentication Failures” zamiast „Identification and Authentication Failures”, „Logging and Alerting” zamiast „Logging and Monitoring”. | Umożliwia lepsze dostosowanie procesów: monitoring + alerting to różne etapy. |
| Nowe wektory | Kategoria „Mishandling of Exceptional Conditions” wskazuje na problem z obsługą błędów/brzegowych przypadków – częściej w microservices/AI/edge. | Wymaga rewizji architektury obsługi błędów, fallbacków, eksploatacji wyjątków. |
| „Shift-left” i design | W 2021 już była „Insecure Design”; w 2025 nadal obecna, ale niżej – co może wskazywać, że powinna być już standardem, nie tylko punktem kontrolnym. | Integracja bezpieczeństwa na etapie projektowania, nie tylko w testach. |
| Konfiguracja & operacje | „Security Misconfiguration” przeniesiona na wyższą pozycję – wskazuje, że operacyjna strona bezpieczeństwa (konfiguracje, domyślny deployment) jest nadal słabym punktem. | Warto uwzględnić w ciągłym monitoringu i audytach środowisk produkcyjnych oraz CI/CD. |
Rekomendacje dla zespołów bezpieczeństwa/rozwoju
Na podstawie powyższej analizy, sugerujemy aby zespoły IT/developerskie przyjęły następujące działania:
- Aktualizacja check-list i standardów kodowania
- Wdrożyć kontrolę „Broken Access Control” jako priorytetową: np. model RBAC/ABAC, testy uprawnień, mapowanie ról, minimalne uprawnienia.
- Uzupełnić standardy o „Software Supply Chain Failures”: zarządzanie zależnościami (SCA / software composition analysis), skanowanie kontenerów, pipeline CI/CD, podpisywanie artefaktów.
- Uzupełnić standardy inspekcji błędów wyjątków i warunków brzegowych („Mishandling of Exceptional Conditions”).
- Rozszerzyć testy integracyjne i scenariusze wyjątkowe: co się dzieje gdy np. baza danych jest niedostępna, gdy token wygasł, gdy zasób został usunięty, gdy skrypt kontenera zawiedzie.
- Szkolenia i świadomość
- Zorganizować szkolenia dla developerów i architektów w obszarach: bezpieczeństwo w fazie projektowania („Insecure Design”), supply chain, konfiguracje produkcyjne.
- Uaktualnić materiały onboardingowe: uwzględnić kwestie związane z „Authentication Failures” – np. federacja tożsamości, sesje cookie vs tokeny, automatyczne logowanie, token abuse.
- Procesy Audit / Test / Monitoring
- Wyróżnić w planach testów i audytów: kontrolki dotyczące konfiguracji środowisk produkcyjnych, pipeline CI/CD, monitoring błędów oraz alertów operacyjnych (Logging and Alerting).
- Ustalić metryki: np. liczba zależności ze znanymi lukami, liczba krytycznych błędów uprawnień, liczba incydentów spowodowanych błędną konfiguracją, liczba nieobsłużonych wyjątków w produkcji.
- Włączyć automatyczne narzędzia: SCA-skanery, IaC-drivery konfiguracji (np. Terraform/Azure Bicep/CloudFormation) z regułami bezpieczeństwa, monitoring „wyjątków” w produkcji.
- Integracja z ofertą HEXSSL
- W kontekście naszych susług (certyfikaty SSL/TLS, bezpieczeństwo infrastruktury, konsultacje) – podkreślamy rolę certyfikatów i kryptografii w kategorii „Cryptographic Failures” (A04 2025).
- Proponujemy audyty supply-chain i zależności, zwłaszcza jeśli wykorzystywane są mikroserwisy, kontenery lub integracje SaaS.
Wersja OWASP Top 10 2021 nadal stanowi solidny fundament (i powinna być traktowana jako minimum standardu) – jednak wersja rekordowa 2025 przyciąga uwagę przede wszystkim rozszerzeniem zakresu poza kod do całego ekosystemu aplikacji: artefakty, zależności, operacje, pipeline’y, wyjątkowe warunki, logowanie/alertowanie. Dla zespołów IT oznacza to konieczność podniesienia perspektywy – od „czy kod jest bezpieczny?” do „czy cały proces i runtime produktu jest odporny i monitorowany?”.