OWASP Top 10 (2025 RC1): dwie nowe kategorie ryzyka dla aplikacji webowych

Wprowadzenie do problemu / definicja zmian

OWASP opublikował wersję Release Candidate listy Top 10:2025, która porządkuje najpoważniejsze ryzyka bezpieczeństwa aplikacji webowych. Nowa edycja przynosi dwie nowe kategorie oraz konsolidację (SSRF wchodzi do Broken Access Control). Zestawienie pozostaje „data-informed”, ale nie „data-driven”—autorzy łączą analizę danych z ankietą społeczności, aby wychwycić ryzyka słabo mierzalne narzędziami.

W skrócie

• Nowe kategorie:
  • A03: Software Supply Chain Failures – rozwinięcie dawnego „Vulnerable and Outdated Components” o pełny łańcuch dostaw: zależności, buildy, dystrybucja.
  • A10: Mishandling of Exceptional Conditions – błędne obchodzenie się ze stanami wyjątkowymi (np. „fail open”, ujawnianie szczegółów błędów, brak rollbacków transakcji).
• Konsolidacja: SSRF wchodzi do A01: Broken Access Control.
• Awans: Security Misconfiguration rośnie z #5 (2021) na #2 (2025 RC1).

Kontekst / historia / powiązania

Lista Top 10 to punkt odniesienia dla zespołów AppSec od lat. W 2021 r. największym trzęsieniem ziemi było wyniesienie „Broken Access Control” na #1 oraz wydzielenie „Insecure Design”. W 2025 RC1 zespół OWASP:

• zwiększa liczbę analizowanych CWE do 589 (vs ~400 w 2021),
• kładzie nacisk na przyczynę, nie symptom (root cause),
• korzysta z danych o CVEs/CVSS oraz z ankiety społeczności dla kategorii słabo testowalnych na skalę.

Analiza techniczna / szczegóły

A03: Software Supply Chain Failures (nowa/rozszerzona)

To rozszerzenie dawnego „Vulnerable and Outdated Components” (A06:2021), ale obejmujące cały ekosystem: zależności bezpośrednie i transytywne, narzędzia buildowe, rejestry artefaktów, łańcuch dystrybucji i podpisywanie. Mimo iż kategoria ma niewiele CVE (problem z testowalnością), w ankiecie społeczności była najwyżej oceniana; OWASP podkreśla też wysokie średnie wyniki exploit/impact w CVE. Przykłady: SolarWinds czy kampanie uderzające w marketplace’y rozszerzeń.

Ryzyka techniczne (przykłady CWE):

• CWE-1104: użycie nieutrzymywanych komponentów,
• CWE-1395: zależność od podatnego komponentu,
• CWE-1329: komponent nieaktualizowalny.

A10: Mishandling of Exceptional Conditions (nowa)

Nowa kategoria obejmuje 24 CWE związane z obsługą wyjątków, błędami logiki, „fail open”, wyciekami informacji z komunikatów błędów, brakiem reakcji na stany nadzwyczajne czy niejednolitą obsługą wyjątków. To obszar wcześniej traktowany czasem jako „code quality”, ale jego wpływ bezpieczeństwa jest realny: od DoS i eskalacji uprawnień po naruszenia integralności i poufności.

Ryzyka techniczne (przykłady CWE):

• CWE-209/CWE-550: komunikaty błędów ujawniające dane wrażliwe,
• CWE-636: brak „failing closed”,
• CWE-703/754/755: niewłaściwe sprawdzanie/obsługa warunków wyjątkowych.

Inne przetasowania

• A01 Broken Access Control pozostaje #1 i wchłania SSRF.
• A02 Security Misconfiguration rośnie do #2 (coraz więcej zachowań aplikacji konfiguruje się, a nie koduje).
• A04 Cryptographic Failures oraz A05 Injection spadają o dwa miejsca (na #4 i #5).
• Nazwy doprecyzowano: np. A09 Logging & Alerting Failures (wcześniej „Security Logging and Monitoring Failures”).

Praktyczne konsekwencje / ryzyko

• Łańcuch dostaw: atak na „narzędzia i metry” (IDE, pluginy, pipeline, rejestry, dependency resolvery) często omija klasyczne testy DAST/SAST. Potrzebna jest ciągła widoczność SBOM, kontrola źródeł i podpisy kryptograficzne artefaktów.
• Stany wyjątkowe: błahe z pozoru wyjątki (np. brak parametru) mogą stać się prymitywem eksploitacyjnym (leaki w komunikatach, race condition, brak rollbacku transakcji → fraud). W mikrousługach kaskadowe wyjątki kończą się często DoS lub rozjechanym stanem.

Rekomendacje operacyjne / co zrobić teraz

1) Supply chain security w praktyce

Inwentaryzacja i SBOM:

# SBOM (CycloneDX) – syft syft dir:./ -o cyclonedx-json > sbom.json # SCA – grype (mapowanie do CVE) grype sbom:sbom.json --fail-on high

Weryfikacja artefaktów (Sigstore cosign):

# Podpisanie obrazu cosign sign --key cosign.key registry.example.com/app:1.2.3 # Weryfikacja podpisu cosign verify --key cosign.pub registry.example.com/app:1.2.3

Kontrola źródeł i wersji:

• Zezwalaj tylko na oficjalne rejestry i podpisane paczki (npm, PyPI, Maven, NuGet).
• W CI/CD wymuś pinning wersji i bloker „latest”.
• Regularnie aktualizuj IDE/plug-iny, runner’y, builder’y; traktuj je jak element produkcji.

Narzędzia OWASP, które warto włączyć:

• Dependency-Check / Dependency-Track, CycloneDX, ASVS. (Wprost rekomendowane na stronie A03).

2) Obsługa wyjątków „fail closed” + minimalizacja wycieków

Zasady:

• Zawsze rollback transakcji przy błędach (nie próbuj „naprawiać w locie”).
• Globalny handler wyjątków + spójna polityka komunikatów (przyjaźnie dla użytkownika, bez danych technicznych).
• Logowanie + alerting (SRE/SEC) – powtarzalne błędy mogą sygnalizować atak (brute force, fuzzing).

Przykład (Java/Spring) – bezpieczny handler i rollback:

@RestControllerAdvice public class GlobalExceptionHandler { @ExceptionHandler(Exception.class) public ResponseEntity<ApiError> handleAny(Exception ex, WebRequest req) { // Log szczegółowy trafia do SIEM, nie do użytkownika MDC.put("correlationId", UUID.randomUUID().toString()); log.error("Unhandled exception", ex); // Użytkownik dostaje neutralny komunikat ApiError safe = new ApiError("Wystąpił błąd. Spróbuj ponownie później."); return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR).body(safe); } } @Service public class TransferService { @Transactional public void transferMoney(...) { // jeżeli cokolwiek rzuci wyjątek -> @Transactional zapewni rollback (fail closed) // ... } }

Przykład (Node.js/Express) – brak wycieków w błędach:

app.use((err, req, res, next) => { req.log?.error({ err }, "Unhandled error"); // szczegóły do logów res.status(500).json({ message: "Wystąpił błąd. Spróbuj ponownie." }); // bez stacktrace });

Twarde limity i back-pressure (zapobieganie stanom wyjątkowym):

• Rate limiting (np. NGINX, Envoy) i limity zasobów (CPU, RAM, otwarte pliki).
• Circuit breaker/time-out/retry-with-jitter między usługami.

3) Misconfiguration hygiene

• Kontrola konfiguracji jako kodu (GitOps, PR-y + review).
• Skany konfiguracji (kube-bench, kube-lint, tfsec).
• Separacja obowiązków w CI/CD; nikt nie powinien samodzielnie przepchnąć kodu do produkcji.

Różnice / porównania z innymi przypadkami

• Względem 2021: z kategorii „komponenty podatne/przestarzałe” wyrósł pełny łańcuch dostaw (A03), co odzwierciedla ataki na ekosystem deweloperski i narzędzia (marketplace’y, rejestry, buildy). SSRF przestało być samotną wyspą—logicznie trafiło do Broken Access Control (#1). Security Misconfiguration rośnie, co dobrze koresponduje z IaC/K8s i „konfiguracją-jako-logiką”.

Podsumowanie / najważniejsze wnioski

1. Myśl łańcuchowo: widoczność SBOM, podpisy, polityka źródeł, hardening pipeline’ów są równie ważne jak testy kodu.
2. Przewiduj wyjątkowe: ujednolicone, bezpieczne wzorce obsługi błędów, zasada „fail closed”, realny alerting i rollback.
3. Konfiguracja to kod: traktu­j ją tak samo rygorystycznie (review, testy, skany).
4. Aktualizuj program szkoleniowy AppSec o nowe kategorie i mapowanie CWE/ATT&CK; przestaw wymagania na root cause zamiast pojedynczych symptomów.

Źródła / bibliografia

• SecurityWeek: „Two New Web Application Risk Categories Added to OWASP Top 10”, 10 listopada 2025. (SecurityWeek)
• OWASP Top 10:2025 RC1 – Introduction / What’s changed / Methodology. (OWASP)
• OWASP Top 10:2025 RC1 – A03 Software Supply Chain Failures (opis, CWE, narzędzia). (OWASP)
• OWASP Top 10:2025 RC1 – A10 Mishandling of Exceptional Conditions (opis, CWE, zalecenia). (OWASP)