OWASP Top 10:2025 — dziesięć kategorii ryzyka aplikacji webowych.
OWASP Top 10 to najczęściej cytowana lista ryzyk bezpieczeństwa aplikacji webowych: dziesięć kategorii ułożonych według danych z milionów przebadanych aplikacji i ankiety wśród praktyków. Nie jest listą kontrolną do odhaczenia, tylko wspólnym językiem — mówi, gdzie aplikacje pękają najczęściej i najboleśniej. Tu jest cała edycja 2025, kategoria po kategorii, i uczciwa odpowiedź na pytanie, ile z niej widać ze skanu strony z zewnątrz.
Źródło: OWASP Top 10:2025 (edycja 2025, ósma; licencja CC BY-SA 4.0), odczyt 26.09.2026. Opisy są naszym opracowaniem, nie tłumaczeniem. Kolumny „Na WordPressie” i „Co widzi skaner” odnoszą kategorie do stron, które monitorujemy, i do testów opisanych w Zestawach testów.
- Kategorii
- 102 nowe albo poszerzone
- CWE przypisanych
- 249z 589 przeanalizowanych
- Aplikacji w danych
- 2,8 mln13 dostawców danych
- Widać z zewnątrz
- 8 z 10w pełni 2, reszta częściowo albo po skutkach
Najmocniej awansowała błędna konfiguracja (z 5. na 2. miejsce): coraz więcej zachowania aplikacji ustawia się konfiguracją, nie kodem. Komponenty z lukami (A06:2021) urosły do całego łańcucha dostaw i mają najwyższy średni wpływ w zestawieniu. SSRF przestała być osobną kategorią — to odmiana złamanej kontroli dostępu. Nowa A10 zbiera błędy obsługi sytuacji wyjątkowych, które wcześniej rozpraszały się po jakości kodu.
| Kod | Kategoria | Zmiana wobec 2021 | CWE | Częstość max | Pokrycie śr. | Eksploat. | Wpływ | CVE | Z zewnątrz |
|---|---|---|---|---|---|---|---|---|---|
| A01 | Złamana kontrola dostępuBroken Access Control | bez zmianA01:2021, dalej pierwsza; wchłonęła SSRF (A10:2021) | 40 | 20,15 % | 42,93 % | 7,04 | 3,84 | 32 654 | częściowo |
| A02 | Błędna konfiguracja bezpieczeństwaSecurity Misconfiguration | awansA05:2021 → druga pozycja | 16 | 27,70 % | 52,35 % | 7,96 | 3,97 | 1375 | dobrze |
| A03 | Awarie łańcucha dostaw oprogramowaniaSoftware Supply Chain Failures | rozszerzonaA06:2021 „Vulnerable and Outdated Components” poszerzona o cały łańcuch dostaw | 6 | 9,56 % | 27,47 % | 8,17 | 5,23 | 11 | dobrze |
| A04 | Błędy kryptograficzneCryptographic Failures | spadekA02:2021 → czwarta pozycja | 32 | 13,77 % | 47,74 % | 7,23 | 3,90 | 2185 | częściowo |
| A05 | WstrzyknięciaInjection | spadekA03:2021 → piąta pozycja | 37 | 13,77 % | 42,93 % | 7,15 | 4,32 | 62 445 | skutki |
| A06 | Niebezpieczny projektInsecure Design | spadekA04:2021 → szósta pozycja | 39 | 22,18 % | 35,18 % | 6,96 | 4,05 | 7647 | nie widać |
| A07 | Błędy uwierzytelnianiaAuthentication Failures | nowa nazwaA07:2021 „Identification and Authentication Failures” — ta sama pozycja, krótsza nazwa | 36 | 15,80 % | 37,14 % | 7,69 | 4,44 | 7147 | częściowo |
| A08 | Naruszenie integralności oprogramowania lub danychSoftware or Data Integrity Failures | bez zmianA08:2021 — ta sama pozycja | 14 | 8,98 % | 45,49 % | 7,11 | 4,79 | 3331 | skutki |
| A09 | Braki w logowaniu i alarmowaniuSecurity Logging and Alerting Failures | nowa nazwaA09:2021 „…Monitoring Failures” — nacisk przeniesiony z monitoringu na alarm | 5 | 11,33 % | 46,48 % | 7,19 | 2,65 | 723 | nie widać |
| A10 | Złe obsługiwanie sytuacji wyjątkowychMishandling of Exceptional Conditions | nowanowa kategoria | 24 | 20,67 % | 37,95 % | 7,11 | 3,81 | 3416 | skutki |
| Razem | 249 | 120 934 |
- Kolejność
- Pozycja łączy częstość, pokrycie, łatwość wykorzystania i wpływ; osiem kategorii wynika z danych, dwie dodała ankieta praktyków.
- Z zewnątrz
- Ile kategorii widzi skan strony bez logowania i bez kodu: dobrze · częściowo · skutki (widać dopiero szkodę) · nie widać.
- Liczby
- Definicje kolumn w TAB. 14 na końcu strony.
| Czym jest | Użytkownik robi coś, do czego nie ma prawa: czyta cudze dane, zmienia cudze rekordy, wchodzi do panelu, który go nie dotyczy. Aplikacja wie, kim jest, ale nie sprawdza, czy wolno mu to zrobić. |
|---|---|
| Jak wygląda | 01 Domyślne „wolno” zamiast domyślnego „nie wolno” — nowy zasób jest otwarty, dopóki ktoś nie pamięta go zamknąć.02 Zmiana identyfikatora w adresie (…/faktura/1041 → 1042) pokazuje cudzy dokument (IDOR).03 Endpoint API przyjmuje POST, PUT i DELETE bez sprawdzenia uprawnień, bo „przecież nikt nie zna adresu”.04 Podniesienie uprawnień przez podmianę ciasteczka albo pola w tokenie JWT.05 Wymuszone wejście pod adres panelu, który nie ma linku, ale nie ma też blokady.06 SSRF: serwer pobiera adres podany przez użytkownika i sięga nim do sieci wewnętrznej. |
| Jak zapobiegać | 01 Odmowa domyślnie — wyjątkiem są tylko zasoby publiczne.02 Jeden mechanizm kontroli dostępu użyty w całej aplikacji, nie sprawdzenia rozsiane po widokach.03 Sprawdzanie właściciela rekordu przy każdym odczycie i zapisie.04 Unieważnianie sesji po stronie serwera przy wylogowaniu; krótko żyjące tokeny.05 Limit żądań na API i alarm przy serii odmów dostępu. |
| Charakterystyczne CWE | CWE-284 Improper Access ControlCWE-862 Missing AuthorizationCWE-639 Authorization Bypass Through User-Controlled KeyCWE-352 Cross-Site Request ForgeryCWE-918 Server-Side Request Forgery |
| Liczby | CWE 40 · częstość max 20,15 % / śr. 3,74 % · pokrycie max 100,00 % / śr. 42,93 % · eksploatacja 7,04 · wpływ 3,84 · wystąpienia 1 839 701 · CVE 32 654 |
| Na WordPressie | Najczęstszy wzorzec w podatnościach wtyczek: trasa REST albo akcja AJAX bez sprawdzenia uprawnień (brak permission_callback, brak current_user_can) i brak nonce, czyli CSRF. Rdzeń WordPressa sam ujawnia loginy autorów (/wp-json/wp/v2/users, ?author=1) i ma pingback w XML-RPC, który bywa używany jako SSRF. |
| Co widzi skaner | częściowo exposureWidzi objawy wystawienia: wyliczanie użytkowników (exposure_users_enum, exposure_author_enum), otwartą rejestrację (open_registration) i XML-RPC (exposure_xmlrpc). Nie widzi brakującego sprawdzenia uprawnień we wtyczce — to wymaga zalogowania i znajomości kodu; znane przypadki łapie dopiero dopasowanie wersji do CVE (A03). |
| Czym jest | System, serwer albo usługa chmurowa ustawione źle z punktu widzenia bezpieczeństwa. Kod może być poprawny — dziurę robi to, jak go wdrożono i co zostało włączone. |
|---|---|
| Jak wygląda | 01 Przykładowe aplikacje i konta z domyślnym hasłem zostawione na serwerze produkcyjnym.02 Włączone listowanie katalogów — każdy może pobrać pliki, których nikt nie linkował.03 Szczegółowe komunikaty błędów ze śladem stosu i wersjami komponentów.04 Zasobnik w chmurze udostępniony „każdemu z linkiem” albo całemu internetowi.05 Brak nagłówków bezpieczeństwa albo ustawienia, które je osłabiają.06 Zbędne usługi, porty i funkcje pozostawione włączone. |
| Jak zapobiegać | 01 Powtarzalny proces utwardzania — każde środowisko stawiane tak samo, najlepiej automatem.02 Usunięcie wszystkiego, co niepotrzebne: przykładów, dokumentacji, nieużywanych modułów.03 Wyłączone listowanie katalogów i ogólne komunikaty błędów dla użytkownika.04 Nagłówki bezpieczeństwa wysyłane do przeglądarki (HSTS, CSP, X-Content-Type-Options…).05 Automatyczna weryfikacja konfiguracji we wszystkich środowiskach; przegląd przy każdej łatce. |
| Charakterystyczne CWE | CWE-16 ConfigurationCWE-611 XML External Entity Reference (XXE)CWE-489 Active Debug CodeCWE-526 Exposure of Sensitive Information Through Environmental Variables |
| Liczby | CWE 16 · częstość max 27,70 % / śr. 3,00 % · pokrycie max 100,00 % / śr. 52,35 % · eksploatacja 7,96 · wpływ 3,97 · wystąpienia 719 084 · CVE 1375 |
| Na WordPressie | Klasyka stron firmowych: kopia wp-config.php.bak w katalogu głównym, pozostawiony debug.log, phpinfo.php po instalacji, katalog .git wgrany razem ze stroną, listowanie /wp-content/uploads/, zrzut bazy .sql po migracji. Każdy z tych plików da się pobrać jednym żądaniem. |
| Co widzi skaner | dobrze exposure · security_headersNajlepiej pokryta kategoria. Test exposure to 25 sond ścieżek (.env, .git, kopie wp-config, zrzuty SQL, archiwa, phpinfo, konsola bazy, debug.log, listowanie katalogów, kopie .htaccess). Test security_headers sprawdza sześć nagłówków ochronnych. Nie widać konfiguracji, która nie zostawia śladu w odpowiedzi HTTP (uprawnienia plików, ustawienia bazy, panel hostingu). |
| Czym jest | Złamanie albo zaniedbanie w procesie budowania, dystrybucji i aktualizowania oprogramowania — od przestarzałej biblioteki po przejęte konto opiekuna pakietu i skompromitowany pipeline. |
|---|---|
| Jak wygląda | 01 Komponenty stare albo porzucone przez autorów, nadal działające na produkcji.02 Brak wiedzy, jakie zależności przechodnie siedzą pod spodem.03 Kod z niezweryfikowanego źródła wgrany bez przeglądu.04 Łatki instalowane miesiącami po publikacji podatności.05 Słabo chronione repozytoria i pipeline’y budowania; jedna osoba może wszystko. |
| Jak zapobiegać | 01 Spis składników (SBOM) — wiesz, co masz, łącznie z zależnościami zależności.02 Stałe śledzenie baz CVE i biuletynów producentów.03 Komponenty tylko z oficjalnych źródeł, bezpiecznym kanałem.04 Wdrożenia etapowe, żeby przejęty dostawca nie trafił od razu wszędzie.05 MFA i rozdział obowiązków w repozytoriach, CI/CD i narzędziach deweloperskich. |
| Charakterystyczne CWE | CWE-1104 Use of Unmaintained Third Party ComponentsCWE-1395 Dependency on Vulnerable Third-Party ComponentCWE-1357 Reliance on Insufficiently Trustworthy ComponentCWE-1329 Reliance on Component That is Not UpdateableCWE-447 Use of Obsolete Function |
| Liczby | CWE 6 · częstość max 9,56 % / śr. 5,72 % · pokrycie max 65,42 % / śr. 27,47 % · eksploatacja 8,17 · wpływ 5,23 · wystąpienia 215 248 · CVE 11 |
| Na WordPressie | Tu leży większość realnych włamań na strony WordPress: nieaktualne wtyczki i motywy, wtyczki wycofane z katalogu wordpress.org, „nulled” motywy premium z doklejonym kodem, motyw kupiony raz i nigdy nieaktualizowany. Najwyższy średni wpływ ze wszystkich kategorii (5,23) zgadza się z tym, co widzimy w portfolio. |
| Co widzi skaner | dobrze wp_fingerprint · vuln_match · version_summary · wpscanRdzeń naszego skanera: wp_fingerprint ustala z zewnątrz wersje rdzenia, wtyczek, motywu i PHP; vuln_match i version_summary porównują je z indeksem podatności Wordfence; wpscan dociąga wtyczki, których Wordfence nie zna. Katalog Wiedza → Rozszerzenia pokazuje wtyczki wycofane. Granica: wtyczka, która nie zdradza wersji z zewnątrz, zostaje „wersja nieznana”, a nie „czysta”. |
| Czym jest | Brak szyfrowania, szyfrowanie za słabe, klucze w złym miejscu albo błędy w użyciu kryptografii — skutkiem jest ujawnienie danych, które miały być chronione. |
|---|---|
| Jak wygląda | 01 Dane przesyłane bez szyfrowania — sesję da się przejąć w otwartej sieci.02 Hasła hashowane słabym albo niesolonym algorytmem, łamane tablicami tęczowymi.03 Klucze kryptograficzne zaszyte w kodzie źródłowym albo domyślne.04 Przestarzałe algorytmy (MD5, SHA-1) i ponownie użyte wektory inicjujące.05 Brak weryfikacji certyfikatu i łańcucha zaufania. |
| Jak zapobiegać | 01 Szyfrowanie danych wrażliwych w spoczynku i TLS 1.2 lub nowszy w transmisji.02 Hasła tylko przez adaptacyjne, solone funkcje z czynnikiem pracy (np. Argon2, bcrypt).03 Klucze w HSM albo menedżerze sekretów, nigdy w repozytorium.04 Szyfrowanie uwierzytelnione zamiast „gołego” szyfrowania.05 Brak cache’owania odpowiedzi z danymi wrażliwymi; przygotowanie na kryptografię postkwantową. |
| Charakterystyczne CWE | CWE-327 Use of a Broken or Risky Cryptographic AlgorithmCWE-916 Use of Password Hash With Insufficient Computational EffortCWE-759 Use of a One-Way Hash without a SaltCWE-338 Use of Cryptographically Weak PRNGCWE-331 Insufficient Entropy |
| Liczby | CWE 32 · częstość max 13,77 % / śr. 3,80 % · pokrycie max 100,00 % / śr. 47,74 % · eksploatacja 7,23 · wpływ 3,90 · wystąpienia 1 665 348 · CVE 2185 |
| Na WordPressie | Na stronie firmowej to głównie warstwa transportu: certyfikat, który się nie odnowił, brak przekierowania na https://, obrazki i skrypty ładowane przez http:// (mixed content), brak HSTS. Hashowanie haseł załatwia rdzeń — od WordPressa 6.8 domyślnie bcrypt zamiast phpass. |
| Co widzi skaner | częściowo ssl · redirect · mixed_content · security_headersWidzi transport: ssl (ważność i zgodność nazwy certyfikatu), redirect (http → https), mixed_content, brak HSTS w security_headers. Nie widzi niczego po stronie serwera — jak są przechowywane hasła, klucze i dane w bazie. |
| Czym jest | Dane od użytkownika trafiają do interpretera — bazy, przeglądarki, powłoki — i ten wykonuje ich część jako polecenie. Najwięcej CVE ze wszystkich kategorii (62 445). |
|---|---|
| Jak wygląda | 01 SQL injection — parametr zmienia logikę zapytania (' OR '1'='1).02 Cross-site scripting (XSS) — skrypt napastnika trafia na stronę i wykonuje się w przeglądarce ofiary.03 Wstrzyknięcie poleceń systemu operacyjnego przez pole formularza.04 Wstrzyknięcia NoSQL, LDAP i w zapytania ORM. |
| Jak zapobiegać | 01 Bezpieczne API z parametrami — dane nigdy nie są sklejane z poleceniem.02 Walidacja po stronie serwera według listy dozwolonych wartości.03 Escapowanie właściwe dla kontekstu tam, gdzie zapytanie musi być dynamiczne.04 Nazwy tabel i kolumn nigdy z danych użytkownika — tych nie da się bezpiecznie escapować.05 SAST, DAST i fuzzing w pipeline, przegląd kodu miejsc styku z interpreterem. |
| Charakterystyczne CWE | CWE-79 Cross-site Scripting (XSS)CWE-89 SQL InjectionCWE-78 OS Command InjectionCWE-94 Code InjectionCWE-90 LDAP Injection |
| Liczby | CWE 37 · częstość max 13,77 % / śr. 3,08 % · pokrycie max 100,00 % / śr. 42,93 % · eksploatacja 7,15 · wpływ 4,32 · wystąpienia 1 404 249 · CVE 62 445 |
| Na WordPressie | XSS to najczęstszy typ podatności publikowanych dla wtyczek WordPressa, SQL injection jeden z najgroźniejszych (zapytania sklejane zamiast $wpdb->prepare). Skutek widać później jako zainfekowaną stronę: obcy skrypt w szablonie, spam SEO, przekierowania. |
| Co widzi skaner | skutki vuln_match · infection_checkSkaner nie atakuje stron klientów, więc nie próbuje wstrzyknięć. Widzi dwie rzeczy: znane podatności typu XSS/SQLi w zainstalowanych wersjach (vuln_match, przez A03) i skutek udanego wstrzyknięcia w HTML (infection_check: obce skrypty, eval(atob), ukryte ramki, spam SEO). |
| Czym jest | Błąd w samym pomyśle, nie w wykonaniu: brakuje zabezpieczenia, którego nikt nie zaprojektował. Nawet bezbłędna implementacja złego projektu jest podatna. |
|---|---|
| Jak wygląda | 01 Odzyskiwanie konta przez „pytanie pomocnicze”.02 Rezerwacja bez limitu i bez zaliczki — jeden bot wykupuje całą salę.03 Brak ochrony przed botami przy premierze produktu.04 Brak rozdziału danych między klientami w systemie wielodostępnym.05 Założenia procesu (kolejność kroków, limity) nigdzie niesprawdzane. |
| Jak zapobiegać | 01 Bezpieczeństwo od pierwszego dnia projektu, nie na koniec.02 Modelowanie zagrożeń dla logowania, kontroli dostępu i kluczowych procesów.03 Biblioteka sprawdzonych wzorców i komponentów.04 Wymagania bezpieczeństwa wpisane w historie użytkownika.05 Testy jednostkowe i integracyjne, które sprawdzają odporność na zagrożenia z modelu. |
| Charakterystyczne CWE | CWE-269 Improper Privilege ManagementCWE-434 Unrestricted Upload of File with Dangerous TypeCWE-501 Trust Boundary ViolationCWE-522 Insufficiently Protected CredentialsCWE-256 Unprotected Storage of Credentials |
| Liczby | CWE 39 · częstość max 22,18 % / śr. 1,86 % · pokrycie max 88,76 % / śr. 35,18 % · eksploatacja 6,96 · wpływ 4,05 · wystąpienia 729 882 · CVE 7647 |
| Na WordPressie | Formularz, który przyjmuje dowolny plik do katalogu uploads; sklep bez limitu kuponów; strona, na której każdy redaktor jest administratorem, „bo tak prościej”. To decyzje wdrożeniowe i biznesowe — żaden skan wersji ich nie znajdzie. |
| Co widzi skaner | nie widać Z zewnątrz nie widać. Projekt ocenia się na przeglądzie: rozmowa o procesach, role użytkowników, przegląd formularzy i integracji. Otwarta rejestracja (open_registration) bywa objawem złej decyzji projektowej, ale sama nie jest dowodem. |
| Czym jest | System uznaje kogoś za prawowitego użytkownika, choć nim nie jest — przez zgadnięte hasło, wykradzione dane logowania albo źle zarządzaną sesję. |
|---|---|
| Jak wygląda | 01 Credential stuffing — logowanie listami haseł z cudzych wycieków.02 Password spraying z przewidywalnymi hasłami (Zima2025 → Zima2026).03 Brak limitu prób logowania — brute force bez przeszkód.04 Domyślne dane typu admin/admin.05 Brak albo słabe MFA; sesja ważna po wylogowaniu. |
| Jak zapobiegać | 01 Uwierzytelnianie wieloskładnikowe tam, gdzie to możliwe.02 Sprawdzanie nowych haseł z listami wyciekłych i słabych haseł.03 Limit nieudanych logowań i ten sam komunikat dla złego loginu i złego hasła.04 Zarządzanie sesją po stronie serwera, losowe identyfikatory o wysokiej entropii.05 Polityka haseł według NIST 800-63b — bez wymuszonej okresowej zmiany. |
| Charakterystyczne CWE | CWE-287 Improper AuthenticationCWE-307 Improper Restriction of Excessive Authentication AttemptsCWE-798 Use of Hard-coded CredentialsCWE-384 Session FixationCWE-259 Use of Hard-coded Password |
| Liczby | CWE 36 · częstość max 15,80 % / śr. 2,92 % · pokrycie max 100,00 % / śr. 37,14 % · eksploatacja 7,69 · wpływ 4,44 · wystąpienia 1 120 673 · CVE 7147 |
| Na WordPressie | Stały ruch na wp-login.php i xmlrpc.php od botów zgadujących hasła; XML-RPC pozwala sprawdzić setki haseł jednym żądaniem (system.multicall). Loginy są często znane, bo WordPress je ujawnia (A01). Brak 2FA dla administratorów to norma na stronach firmowych. |
| Co widzi skaner | częściowo exposureWidzi to, co ułatwia atak: otwarty XML-RPC (exposure_xmlrpc) i ujawnione loginy (exposure_users_enum, exposure_author_enum) — połowę danych potrzebnych do zgadywania. Nie widzi siły haseł, MFA ani limitów logowania: sprawdzenie ich z zewnątrz byłoby atakiem. |
| Czym jest | System przyjmuje kod albo dane jako zaufane, nie sprawdzając, skąd pochodzą i czy ktoś ich po drodze nie zmienił. |
|---|---|
| Jak wygląda | 01 Aktualizacje instalowane bez weryfikacji podpisu.02 Wtyczki i skrypty z niesprawdzonych repozytoriów i CDN-ów.03 Pipeline CI/CD, który pobiera kod bez kontroli integralności.04 Deserializacja obiektów od klienta bez walidacji.05 Funkcje na domenie łudząco podobnej, z tym samym ciasteczkiem logowania. |
| Jak zapobiegać | 01 Podpisy cyfrowe albo sumy kontrolne dla kodu i aktualizacji.02 Zależności tylko z zaufanych repozytoriów, najlepiej własnego, sprawdzonego lustra.03 Obowiązkowy przegląd każdej zmiany w pipeline.04 Rozdział uprawnień i kontrola dostępu w CI/CD.05 Odrzucanie niepodpisanych danych serializowanych. |
| Charakterystyczne CWE | CWE-829 Inclusion of Functionality from Untrusted Control SphereCWE-502 Deserialization of Untrusted DataCWE-494 Download of Code Without Integrity CheckCWE-830 Inclusion of Web Functionality from an Untrusted Source |
| Liczby | CWE 14 · częstość max 8,98 % / śr. 2,75 % · pokrycie max 78,52 % / śr. 45,49 % · eksploatacja 7,11 · wpływ 4,79 · wystąpienia 501 327 · CVE 3331 |
| Na WordPressie | PHP Object Injection (deserializacja przez unserialize) to częsty typ krytycznych CVE we wtyczkach. Do tego skrypty ładowane z obcych domen bez SRI i kampanie, które podmieniają plik JS na samej stronie (SocGholish, EtherHiding). Zmiana serwerów nazw albo MX bez wiedzy właściciela to naruszenie integralności na poziomie domeny. |
| Co widzi skaner | skutki infection_check · dns_integrity_check · ip_changeWidzi skutki: infection_check wykrywa obce i podmienione skrypty (infection_foreign_script, infection_same_origin_loader, infection_socgholish_gateway, infection_etherhiding), dns_integrity_check — dryf NS, MX, SPF i DMARC względem linii bazowej, ip_change — zmianę adresów. Nie widzi, czy aktualizacje i pipeline są podpisane. |
| Czym jest | Bez logów nie da się wykryć ataku, a bez alarmu nie da się na niego szybko zareagować. Zmiana nazwy mówi wprost: log, którego nikt nie czyta, nie chroni. |
|---|---|
| Jak wygląda | 01 Logowane tylko udane logowania, nieudane giną.02 Logi tylko na tym samym serwerze — włamywacz kasuje je razem ze śladami.03 Dane osobowe w logach.04 Progi alarmów tak czułe, że zespół przestaje na nie patrzeć.05 Skan podatności przechodzi przez system i nie wywołuje żadnego alarmu. |
| Jak zapobiegać | 01 Logowanie nieudanych logowań, odmów dostępu i błędów walidacji z kontekstem.02 Poprawne kodowanie wpisów — log też bywa celem wstrzyknięcia.03 Ślad audytowy tylko do dopisywania, z kontrolą integralności.04 Plan reagowania na incydent (np. według NIST 800-61r2).05 Reguły alarmów oddzielające zdarzenia krytyczne od rutyny. |
| Charakterystyczne CWE | CWE-778 Insufficient LoggingCWE-117 Improper Output Neutralization for LogsCWE-532 Insertion of Sensitive Information into Log FileCWE-223 Omission of Security-relevant Information |
| Liczby | CWE 5 · częstość max 11,33 % / śr. 3,91 % · pokrycie max 85,96 % / śr. 46,48 % · eksploatacja 7,19 · wpływ 2,65 · wystąpienia 260 288 · CVE 723 |
| Na WordPressie | Typowa strona firmowa nie ma żadnego logu zdarzeń bezpieczeństwa poza logami serwera u hostingodawcy, których nikt nie przegląda. Właściciel dowiaduje się o włamaniu od klienta albo od Google. |
| Co widzi skaner | nie widać Z zewnątrz nie widać, czy strona loguje. LAB247 działa jako zewnętrzna warstwa alarmu — skan, który znajdzie infekcję albo wystawiony plik, zakłada zgłoszenie — ale to nie zastępuje logów na serwerze: widzimy skutek, a nie przebieg ataku. |
| Czym jest | Program nie przewiduje, nie wykrywa albo źle reaguje na sytuację nietypową — i wtedy się wysypuje, ujawnia wnętrze albo zostaje w stanie, którego nikt nie planował. |
|---|---|
| Jak wygląda | 01 Obsługa wyjątku nie zwalnia zasobów — kilka złośliwych żądań wyczerpuje serwer.02 Komunikat błędu pokazuje ścieżki, zapytania i wersje.03 Wieloetapowa transakcja przerwana w połowie bez wycofania.04 Nieobsłużony wyjątek zostawia system w nieprzewidzianym stanie.05 „Fail open” — przy błędzie kontrola dostępu przepuszcza zamiast blokować. |
| Jak zapobiegać | 01 Łapanie wyjątków tam, gdzie powstają, z sensowną odpowiedzią, logiem i alarmem.02 Bezpieczna porażka (fail closed): błąd = wycofanie całej operacji.03 Globalny handler wyjątków jako siatka bezpieczeństwa.04 Limity żądań i zasobów, żeby sytuacja wyjątkowa nie stała się normą.05 Obserwowanie serii błędów — powtarzalny błąd bywa atakiem. |
| Charakterystyczne CWE | CWE-703 Improper Check or Handling of Exceptional ConditionsCWE-209 Error Message Containing Sensitive InformationCWE-636 Not Failing Securely (Failing Open)CWE-476 NULL Pointer Dereference |
| Liczby | CWE 24 · częstość max 20,67 % / śr. 2,95 % · pokrycie max 100,00 % / śr. 37,95 % · eksploatacja 7,11 · wpływ 3,81 · wystąpienia 769 581 · CVE 3416 |
| Na WordPressie | Włączony WP_DEBUG_DISPLAY na produkcji wypisuje ostrzeżenia PHP ze ścieżkami serwera; wtyczka, która po aktualizacji PHP rzuca błąd krytyczny, kładzie całą stronę („Na stronie wystąpił błąd krytyczny”). |
| Co widzi skaner | skutki http · exposureWidzi skutki: http łapie odpowiedzi 5xx, exposure — wystawiony debug.log i phpinfo (ujawnianie wnętrza, CWE-209). Nie widzi, jak kod obsługuje błędy, dopóki błąd nie wyjdzie na zewnątrz. |
| Test | Kategorie | Co widzi |
|---|---|---|
| exposure | A02 · A01 · A07 · A10 | 25 sond wystawionych plików i endpointów: konfiguracja, loginy, XML-RPC, logi błędów. |
| security_headers | A02 · A04 | Sześć nagłówków ochronnych; brak HSTS to także słabość transportu. |
| wp_fingerprint | A03 | Wersje rdzenia, wtyczek, motywu i PHP ustalone z zewnątrz — wejście do dopasowania CVE. |
| vuln_match · version_summary · wpscan | A03 · A05 · A01 | Znane CVE w zainstalowanych wersjach; typ CVE (XSS, SQLi, brak autoryzacji) wskazuje kategorię. |
| ssl · redirect · mixed_content | A04 | Certyfikat, wymuszenie https://, zasoby po http://. |
| infection_check · safebrowsing | A08 · A05 | Skutek: obcy albo podmieniony kod na stronie, oznaczenie przez Google. |
| dns_integrity_check · ip_change | A08 | Zmiana NS, MX, SPF, DMARC i adresów bez wiedzy właściciela. |
| http | A10 | Odpowiedzi 5xx — objaw nieobsłużonego błędu. |
Test przy kategorii nie znaczy, że kategoria jest sprawdzona. Znaczy, że test widzi jej wycinek — zwykle objaw albo skutek. Brak znaleziska w teście nie jest dowodem, że aplikacja jest wolna od całej kategorii.
| A06 Niebezpieczny projekt | To decyzje, nie pliki i wersje. Ocenia się je na przeglądzie procesów i ról, nie skanem. |
| A09 Logowanie i alarmowanie | Logi są na serwerze. Z zewnątrz można tylko stwierdzić, że skutek ataku przeszedł niezauważony. |
| A01 i A07 — uprawnienia i hasła | Sprawdzenie, czy wtyczka pilnuje uprawnień albo czy hasło jest słabe, wymaga zalogowania albo próby ataku. Nie robimy ani jednego, ani drugiego na stronach klientów. |
| A05 — próby wstrzyknięć | Skaner nie wysyła ładunków ataku. Widzimy znane CVE w wersjach i skutki udanego wstrzyknięcia. |
| Kod własny i konfiguracja serwera | Motyw pisany na zamówienie i ustawienia hostingu nie mają numeru wersji w bazie CVE ani śladu w odpowiedzi HTTP. |
Te luki zamyka przegląd z dostępem: kod wtyczek i motywu, konfiguracja serwera, role użytkowników, logi. Skan z zewnątrz jest czujką, nie audytem zgodności z OWASP.
- CWE
- Liczba słabości z katalogu CWE przypisanych do kategorii. Kategoria to grupa CWE o wspólnej przyczynie, średnio 25 na kategorię.
- Częstość
- Odsetek aplikacji z danym CWE spośród aplikacji przebadanych pod jego kątem; max — najczęstsze CWE kategorii, śr. — średnia po jej CWE.
- Pokrycie
- Odsetek aplikacji przebadanych pod kątem danego CWE — mówi, jak dobrze dane pokrywają kategorię.
- Eksploatacja · wpływ
- Średnie ważone podwyników CVSS (exploitability i impact) z CVE przypisanych do CWE kategorii — im wyżej, tym łatwiej wykorzystać i tym większa szkoda.
- Wystąpienia · CVE
- Łączna liczba aplikacji z trafieniem i liczba CVE przypisanych do CWE kategorii.
Edycja 2025 przeanalizowała 589 CWE (w 2021 około 400) z danych o 2,8 mln aplikacji od 13 organizacji. 8 kategorii wybrano z danych, 2 z ankiety społeczności — dane z testów zawsze mówią o przeszłości, ankieta łapie to, czego narzędzia jeszcze nie umieją mierzyć. Kategorie nazwano według przyczyny, nie objawu: „błędy kryptograficzne” zamiast „wycieku danych wrażliwych”, bo przyczynę da się naprawić, a objaw tylko zauważyć.