OWASP Top 10:2025 w WordPressie: co oznacza każde ryzyko
OWASP Top 10:2025 w realiach WordPressa: jak każde ryzyko wygląda we wtyczkach, motywach i ustawieniach oraz co mogą sprawdzić właściciele stron i programiści.
Także po: English Deutsch Français Español Italiano Português Türkçe
OWASP Top 10 to najbardziej znana lista zagrożeń bezpieczeństwa aplikacji internetowych, a jej wydanie z 2025 roku zastępuje listę z 2021 roku. W przypadku WordPressa czyta się ją jak mapę tego, jak naprawdę dochodzi do włamań na strony: brak sprawdzania uprawnień we wtyczkach, niedbała konfiguracja oraz nieaktualne lub porzucone komponenty.
Ten poradnik przekłada każde z dziesięciu ryzyk na realia WordPressa i pokazuje, które z nich właściciele stron mogą sprawdzić już dziś, a które mogą naprawić w kodzie tylko programiści.
Czym jest OWASP Top 10, a czym nie jest
Listę publikuje OWASP Foundation, organizacja non-profit skupiająca społeczność zajmującą się bezpieczeństwem oprogramowania. OWASP opisuje ją jako „a standard awareness document for developers and web application security” (standardowy dokument podnoszący świadomość, przeznaczony dla programistów i poświęcony bezpieczeństwu aplikacji internetowych). To ranking najpoważniejszych kategorii ryzyka, opracowany na podstawie danych o podatnościach i ankiety przeprowadzonej wśród społeczności.
Nie jest to certyfikat i żadna strona nie jest „zgodna z OWASP”. Lista pomaga zdecydować, od czego zacząć. Jeśli potrzebują Państwo szczegółowego wykazu wymagań, które da się przetestować, OWASP publikuje w tym celu Application Security Verification Standard (ASVS).
Co się zmieniło w 2025 roku
W porównaniu z listą z 2021 roku OWASP Top 10:2025 zawiera dwie nowe kategorie i kilka przetasowań:
- A03 Software Supply Chain Failures to nowość. Rozszerza dawną kategorię „Vulnerable and Outdated Components” (podatne i nieaktualne komponenty) na wszystko, czego używa się do budowania i aktualizowania oprogramowania.
- A10 Mishandling of Exceptional Conditions to również nowość: nieprawidłowa obsługa błędów, błędy logiczne i systemy, które w razie awarii zostają otwarte („fail open”).
- Fałszowanie żądań po stronie serwera (SSRF) nie jest już osobną kategorią; należy teraz do A01 Broken Access Control.
- Security Misconfiguration awansowała z piątego miejsca na drugie.
- A09 nazywa się teraz Security Logging and Alerting Failures – to przypomnienie, że logi, których nikt nie czyta, niczego nie dają.
Dziesięć ryzyk w realiach WordPressa
| OWASP 2025 | Jak to wygląda w WordPressie | Co sprawdzić najpierw |
|---|---|---|
| A01 Broken Access Control | Endpointy AJAX lub REST we wtyczkach bez sprawdzania uprawnień (capabilities) lub nonce | Role i endpointy wtyczek |
| A02 Security Misconfiguration | Komunikaty błędów na stronie produkcyjnej, otwarte listowanie katalogów, kopie zapasowe w katalogu głównym strony | Ustawienia debugowania, konfiguracja serwera |
| A03 Software Supply Chain Failures | Nieaktualne, porzucone lub pirackie („nulled”) wtyczki i motywy | Wykaz wtyczek |
| A04 Cryptographic Failures | Brak HTTPS na każdej podstronie, wyciek kluczy lub kopia wp-config.php do pobrania | HTTPS i sekrety |
| A05 Injection | SQL injection i cross-site scripting w kodzie wtyczek lub motywów | Przegląd kodu, aktualizacje |
| A06 Insecure Design | Funkcje, które ufają przeglądarce, np. cena przesyłana przez klienta | Przegląd projektu |
| A07 Authentication Failures | Słabe lub powtarzane hasła, brak drugiego składnika, nieograniczone próby logowania | 2FA, limity logowania |
| A08 Software or Data Integrity Failures | Zmodyfikowane pliki rdzenia, wstrzyknięty kod, niebezpieczne unserialize() | Sumy kontrolne |
| A09 Security Logging and Alerting Failures | Brak zapisów logowań, nowych administratorów czy zmian plików | Dziennik aktywności |
| A10 Mishandling of Exceptional Conditions | Błędy PHP ujawniające ścieżki, kontrole, które przy awarii przepuszczają | Ustawienia błędów |
Także w WordPressie na szczycie jest Broken Access Control, czyli błędna kontrola dostępu: raport firmy Patchstack State of WordPress Security in 2026 wskazuje ją jako najczęściej wykorzystywaną kategorię podatności w 2025 roku. Patchstack jest dostawcą rozwiązań bezpieczeństwa, dlatego warto traktować ten raport jako jedno, dobrze poinformowane źródło.
Pięć ryzyk, które właściciele stron mogą sprawdzić już dziś
Do tych kontroli nie trzeba czytać kodu. Każda zajmuje kilka minut w kokpicie lub w WP-CLI.
A03: Wykaz i aktualizacja komponentów
Większość podatności w WordPressie kryje się we wtyczkach i motywach, a nie w rdzeniu. Warto prowadzić wykaz komponentów, szybko instalować wydania z poprawkami bezpieczeństwa i usuwać to, czego się nie używa. To polecenie wyświetla wtyczki, na które czeka aktualizacja:
wp plugin list --update=available --fields=name,version,update_version
Porzucone wtyczki i kopie „nulled” szczegółowo omawia nasz poradnik o podatnych wtyczkach WordPress.
A02 i A10: Błędy niewidoczne dla odwiedzających
Działająca strona nigdy nie powinna wyświetlać błędów ani ostrzeżeń PHP, ponieważ ujawniają one ścieżki plików, a czasem szczegóły bazy danych. W pliku wp-config.php na serwerze produkcyjnym debugowanie powinno pozostać wyłączone:
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );
Warto też upewnić się, że serwer nie wyświetla zawartości katalogów i że w obrębie katalogu głównego strony nie są dostępne żadne pliki kopii zapasowych ani eksportów.
A07: Ochrona każdego logowania
Należy włączyć uwierzytelnianie dwuskładnikowe dla wszystkich Administratorów i Redaktorów oraz ograniczyć liczbę nieudanych prób logowania. Nasz poradnik o uwierzytelnianiu dwuskładnikowym w WordPressie omawia dostępne możliwości, od aplikacji uwierzytelniających po klucze dostępu (passkeys).
A08: Sprawdzenie, czy pliki są oryginalne
WP-CLI porównuje Państwa pliki z oficjalnymi sumami kontrolnymi z WordPress.org:
wp core verify-checksums
wp plugin verify-checksums --all
Każdy zmieniony lub nieznany plik w rdzeniu wymaga sprawdzenia. Wtyczek spoza WordPress.org nie da się w ten sposób zweryfikować; należy je porównać ze świeżo pobraną kopią od producenta.
A09: Zapisy zdarzeń i alerty
Warto rejestrować logowania, nowych użytkowników, zmiany ról, instalacje wtyczek i zmiany plików oraz zadbać o to, by ktoś otrzymywał alerty. Bez tych zapisów nie da się ustalić, co się stało po incydencie, ani dotrzymać 72-godzinnego terminu zgłoszenia z RODO, który opisujemy w poradniku o naruszeniach ochrony danych.
Trzy ryzyka, które mogą naprawić tylko programiści
Jeśli tworzą Państwo wtyczki lub motywy, w przypadku A01, A05 i A10 chodzi głównie o kilka funkcji WordPressa, stosowanych konsekwentnie.
- Kontrola dostępu (A01): przed każdą operacją wymagającą uprawnień należy wywołać
current_user_can(), weryfikować nonce za pomocącheck_ajax_referer()lubwp_verify_nonce()i nadać każdej trasie RESTpermission_callback. Od WordPressa 5.5 trasa bez tego parametru wywołuje komunikat (notice); dla tras, które mają być publiczne, WordPress zaleca__return_true. - SSRF (obecnie część A01): jeśli pobierają Państwo adres URL podany przez użytkownika, należy użyć
wp_safe_remote_get(). Funkcja sprawdza adres i każde przekierowanie, a domyślnie odrzuca sieci lokalne i prywatne. - Wstrzykiwanie (A05): zapytania należy budować za pomocą
$wpdb->prepare(), dane wejściowe oczyszczać od razu po ich otrzymaniu (sanitize_text_field(),absint()), a dane wyjściowe escapować jak najpóźniej (esc_html(),esc_attr(),esc_url()). - Sytuacje wyjątkowe (A10): przy każdym wywołaniu, które może się nie powieść, należy sprawdzać
is_wp_error(), a kontrole bezpieczeństwa projektować tak, by w razie awarii blokowały („fail closed”): jeśli sprawdzenia uprawnień lub licencji nie da się dokończyć, operację należy odrzucić.
Trasa REST zgodna z tymi zasadami wygląda tak:
register_rest_route( 'myplugin/v1', '/report', array(
'methods' => 'POST',
'callback' => 'myplugin_save_report',
'permission_callback' => function () {
return current_user_can( 'manage_options' );
},
) );
Rozdział o bezpieczeństwie w podręczniku dla programistów WordPressa objaśnia każdą z tych funkcji na przykładach.
OWASP, RODO i NIS2
OWASP Top 10 nie jest przepisem prawa, ale często służy jako punkt odniesienia dla „stanu wiedzy technicznej” w bezpieczeństwie aplikacji internetowych. Art. 32 RODO wymaga odpowiednich środków technicznych oraz procesu regularnego testowania, mierzenia i oceniania ich skuteczności. Sprawdzenie strony na WordPressie pod kątem dziesięciu kategorii to praktyczny sposób, by wykazać istnienie takiego procesu.
W przypadku podmiotów objętych NIS2 art. 21 ust. 2 wymienia wśród minimalnych środków bezpieczeństwo w procesie nabywania, rozwoju i utrzymania systemów, w tym postępowanie z podatnościami. A03 i A05 odpowiadają bezpośrednio temu obowiązkowi.
Nasza wtyczka Security Audit & Compliance przypisuje każdy wynik do kategorii OWASP Top 10:2025, obok art. 32 RODO i art. 21 NIS2, dzięki czemu raport pokazuje, do którego ryzyka należy dany problem. Wtyczka wykrywa i raportuje; o naprawie decydują Państwo. Więcej o tym, co sprawdza wtyczka.
Najczęstsze pytania
Czy OWASP Top 10 jest wymogiem prawnym?
Nie. To dokument podnoszący świadomość. Przepisy takie jak RODO wymagają odpowiedniego poziomu bezpieczeństwa, a Top 10 pomaga ustalić, co to oznacza w przypadku strony internetowej.
Czy z powodu wydania 2025 trzeba powtórzyć przegląd bezpieczeństwa?
Nie od zera. Większość ryzyk pozostała na liście; wystarczy uzupełnić notatki o nowe kategorie A03 i A10 oraz nową numerację.
Czy sam rdzeń WordPressa jest dużym ryzykiem w rozumieniu OWASP?
Rzadko. Patchstack naliczył w 2025 roku sześć podatności w rdzeniu, wszystkie o niskim priorytecie, wobec tysięcy we wtyczkach i motywach. Ryzyko kryje się w Państwa liście wtyczek.
Ten artykuł ma charakter ogólnoinformacyjny i nie stanowi porady prawnej.
Sprawdź swoją stronę
Security Audit & Compliance to wtyczka WordPress od secaudit.eu: wyszukuje złośliwe oprogramowanie, ukryty spam, zmienione pliki rdzenia i podatny kod oraz przypisuje wyniki do art. 32 RODO, art. 21 NIS2 i OWASP Top 10.
Zobacz, co sprawdza wtyczka