Pojawiła się długo wyczekiwana aktualizacja listy OWASP Top Ten!

OWASP właśnie ogłosił wydanie Release Candidate (RC1 z dnia 6 listopada 2025) nowej wersji znanej na całym świecie listy najbardziej istotnych klas problemów bezpieczeństwa aplikacji webowych – OWASP Top 10:2025. To już ósma edycja (poprzednia pochodziła z 2021 roku), która stanowi punkt odniesienia dla programistów, testerów bezpieczeństwa i całej branży IT pod kątem bezpieczeństwa aplikacji webowych.

Co to jest projekt OWASP Top Ten?

Jest to cyklicznie aktualizowany projekt, który stanowi pewien punkt odniesienia w branży cyberbezpieczeństwa, konkretnie aplikacji webowych. Jego głównym celem jest identyfikacja oraz prezentacja dziesięciu najbardziej poważnych i powszechnych kategorii problemów bezpieczeństwa. Zestawienie powstaje na podstawie analizy globalnych danych (próbek) pochodzących z tysięcy rzeczywistych incydentów, audytów i raportów prowadzonych przez firmy partnerskie projektu, badaczy bezpieczeństwa oraz samą społeczność OWASP.

Projekt ten, adresowany jest przede wszystkim do programistów (deweloperów), architektów i pentesterów, a także osób odpowiedzialnych za bezpieczeństwo IT, mając na celu podnoszenie świadomości w zakresie zagrożeń i popularyzację dobrych, branżowych praktyk. Projekt zawiera nie tylko opisy kategorii problemów, ale również praktyczne wskazówki przeciwdziałania im, mapowanie podatności do CWE (ang. Common Weakness Enumeration), przykłady ataków oraz rekomendacje dla procesu tworzenia i testowania bezpiecznego oprogramowania.

Dlaczego to ważne? Świat się zmienił

Projekt OWASP Top Ten oparty na danych z prawie 3 milionów przebadanych aplikacji pokazuje, że zagrożenia związane z bezpieczeństwem ewoluują wraz z rozwojem technologii (w tym AI). Nowe wydanie przynosi dwie całkowicie nowe kategorie zagrożeń i jedną połączoną (podatność SSRF obecnie należy do A01:2025-Broken Access Control), co sygnalizuje przesunięcie się problemów bezpieczeństwa w kierunku łańcucha dostaw (ang. supply chain) oprogramowania i zarządzania błędami.

Najnowsze wydanie prezentuje się następująco:

​

    A01:2025 – Broken Access Control (błędy w kontroli dostępu)

    A02:2025 – Security Misconfiguration (w konfiguracjach bezpieczeństwa)

    A03:2025 – Software Supply Chain Failures (błędy w łańcuchach dostaw, NOWOŚĆ)

    A04:2025 – Cryptographic Failures (błędy implementacji kryptograficznych)

    A05:2025 – Injection (szeroko pojęte wstrzykiwanie kodu)

    A06:2025 – Insecure Design (niebezpieczne projektowanie rozwiązań, bez dobrych praktych bezpieczeństwa)

    A07:2025 – Authentication Failures (błędy uwierzytelniania)

    A08:2025 – Software or Data Integrity Failures (błędy integralności oprogramowania lub danych)

    A09:2025 – Logging & Alerting Failures (błędy związane z logowaniem i alarmowaniem ich samych)

    A10:2025 – Mishandling of Exceptional Conditions (błędna obsługa wyjątków, NOWOŚĆ)

Główne zmiany w stosunku do wersji 2021

Błędy konfiguracji (ang. Security Misconfiguration) awansują na drugie miejsce!

​Kategoria przesunęła się z piątego miejsca (2021) na drugie (2025). 100% przebadanych aplikacji wykazało co najmniej jedną formę błędnej konfiguracji ze średnim wskaźnikiem incydentów wynoszącym 3,00%, czyli średniej liczby wszystkich badanych incydentów (w tym realne ataki, wycieki, badania), która dla tej edycji wynosiła 2.8 mln próbek. To ogromny sygnał – w dobie infrastruktury chmurowej, poprzez bardzo skomplikowane konfiguracje systemowe, błędy te stały się powszechnym problemem. Zalicza się tutaj między innymi:

• nieusunięte aplikacje (np. testowe) z serwerów produkcyjnych
• konta domyślne z niezmienionym hasłem (serio, 2025?)
• zbyt szczegółowe komunikaty błędów ujawniające architekturę systemu (wersje, stack technologiczny)
• brakujące nagłówki bezpieczeństwa (np. HSTS)
• niewłaściwie skonfigurowane uprawnienia w usługach chmurowych (np. dostęp do AWS S3Bucket z pełnymi prawami zapisu i odczytu dla każdego)

Software Supply Chain Failures – nowa kategoria na miejscu trzecim!

​Zagrożenia związane z naruszeniem łańcuchu dostaw oprogramowania awansowały na trzecie miejsce i to na podstawie jednoznacznej decyzji społeczności – 100% respondentów ankiety OWASP umieściło to zagrożenie w top 3, a 50% wskazało je jako największy problem. Nas jako redakcji, wcale to nie dziwi. Wielokrotnie publikowaliśmy na łamach sekuraka ten problem, np. dotyczący npm, znowu w npm, a także ponownie npm, w bibliotece Golang, PyPi, i wszelkie możliwe “klony” znanego ataku na SolarWinds. Nawet wczoraj. Kategoria ta rozszerza się poza sam problem starych bibliotek (który był zawarty w edycji z 2021 roku) i obejmuje:

• naruszenia bezpieczeństwa systemów budowania oprogramowania – ataki na CI/CD, serwery związane z kompilacją, IDE programistów (jak SolarWinds w 2020)
• słabości infrastruktury aplikacji i mechanizmów wdrożeniowych – podatne API, niezabezpieczone konfiguracje, wyciekające sekrety w kodzie
• problemy z zależnościami (3rd party) – biblioteki open-source, obrazy kontenerów, często spotykany wstrzyknięty złośliwy kod w popularne repozytoria (npm, PyPI)

Błędne implementacje rozwiązań kryptograficznych na miejscu czwartym!

​Błędy kryptograficzne spadły z drugiej pozycji (2021), ale pozostają nadal krytyczne. Zawierają one m.in. problemy z szyfrowaniem danych, słabe algorytmy (np. funkcje skrótu jak MD5, SHA-1 czy starsze metody kryptograficzne – PKCS1 v1.5), niezabezpieczone klucze czy niezaszyfrowane dane w tranzycie.

Nowa kategoria, czyli Mishandling of Exceptional Conditions

To całkowicie nowe zagrożenie, które podkreśla znaczenie prawidłowego obsługiwania błędów i wyjątków. Kategoria ta obejmuje:

• ujawniane w błędach informacji wrażliwych z punktu widzenia bezpieczeństwa (stack traces, wersje komponentów)
• słabe alertowanie (np. zasoby zostały wyczerpane za pomocą DoS podczas uploadu pliku – brak informacji o problemie) i monitoring incydentów bezpieczeństwa
• brak mechanizmów bezpiecznej obsługi błędów (np. prezentacja użytkownikowi pełnego błędu z bazy danych) i anomalii (np. przerwy w połączeniu sieciowym podczas transakcji bankowej) w oprogramowaniu

Zespół OWASP prosi o opinie i Pull Requesty do 20 listopada 2025, co oznacza, że finalne wydanie powinno zostać opublikowane krótko po tym terminie. Z doświadczenia wiemy, że z reguły Release Candidate zostanie zaakceptowane w proponowanej formule.

~tt