Mishandling of Exceptional Conditions: Weryfikacja konfiguracji

Weryfikacja konfiguracji aplikacji i serwera

Punktem odniesienia jest sekcja V16.5 Error Handling w OWASP ASVS 5.0 (maj 2025):

Wymaganie	Poziom	Treść (skrót)
16.5.1	L2	Przy nieoczekiwanym lub wrażliwym błędzie użytkownik dostaje ogólny komunikat — bez stack trace'ów, zapytań, kluczy i tokenów.
16.5.2	L2	Aplikacja działa bezpiecznie, gdy zawodzi dostęp do zasobu zewnętrznego (np. circuit breaker, graceful degradation).
16.5.3	L2	Aplikacja zawodzi bezpiecznie także przy wyjątku — bez fail open, np. bez przetworzenia transakcji mimo błędu walidacji.
16.5.4	L3	Istnieje handler „ostatniej szansy", który łapie wszystkie nieobsłużone wyjątki — żeby nie zgubić danych do logów i nie położyć całego procesu.

ASVS zaznacza, że w językach bez wyjątków (np. Go, Swift) trzeba użyć wzorca właściwego dla języka, który zapewni ten sam efekt.

Najczęstsza przyczyna wycieku stack trace'ów to aplikacja uruchomiona w trybie deweloperskim. Sprawdź:

Technologia	Co zweryfikować
Django	`DEBUG = False` na produkcji
Flask	brak `debug=True` / `FLASK_DEBUG` na produkcji
Express (Node.js)	`NODE_ENV=production` — w tym trybie domyślny handler błędów nie zwraca stack trace'a
ASP.NET Core	`ASPNETCORE_ENVIRONMENT` na produkcji różne od `Development` (od .NET 6 strona deweloperska włącza się w Development automatycznie); na produkcji `UseExceptionHandler(...)`
Spring Boot	`server.error.include-stacktrace` ustawione na `never`; brak wystawionych endpointów Actuatora z danymi diagnostycznymi
PHP	`display_errors = Off`, `log_errors = On`

Własne strony błędów dla 4xx i 5xx (brak domyślnych stron z wersją serwera — CWE-756).
Ukryta wersja serwera (server_tokens off w nginx, ServerTokens Prod i ServerSignature Off w Apache).
Spójny format błędów między reverse proxy a aplikacją — inaczej różnice zdradzają architekturę.

Czy istnieje jeden, centralny mechanizm obsługi błędów i globalny handler?
Czy w kodzie nie ma pustych bloków catch ani łapania ogólnego wyjątku bez decyzji (CWE-390, CWE-396)?
Czy operacje wieloetapowe są w transakcji, która przy błędzie wycofuje całość?
Czy wywołania zależności mają timeouty i czy ich przekroczenie kończy się odmową, a nie pominięciem kontroli?
Czy instrukcje switch / match na rolach i typach mają gałąź default, która odmawia?
Czy zasoby (pliki, połączenia) są zwalniane także na ścieżce błędu (finally, using, with, defer)?

Szczegóły błędu trafiają do logów, nie do odpowiedzi — ale bez haseł, tokenów i pełnych żądań.
Powtarzające się błędy są agregowane i wyzwalają alert — seria błędów to często sygnał, że ktoś testuje obsługę błędów (powiązanie z A09:2025).

Konfiguracja produkcyjna powinna być sprawdzana automatycznie w pipeline (np. test, że strona błędu nie zawiera stack trace'a).
Po każdym wdrożeniu wykonaj smoke test, który wywołuje błąd i sprawdza treść odpowiedzi.

W kolejnym kroku: Narzędzia do testowania