OWASP Top 10 (2025 RC1): dwie nowe kategorie ryzyka dla aplikacji webowych - Security Bez Tabu

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 że 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śli 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 / kluczowe 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)

Jeden komentarz do “OWASP Top 10 (2025 RC1): dwie nowe kategorie ryzyka dla aplikacji webowych”

Możliwość komentowania została wyłączona.