secaudit.eu
Zabezpieczenia

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.

Autorka: , AngelForce OÜ 6 min czytania

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

Diagram: dziesięć ryzyk OWASP Top 10:2025 pogrupowanych według miejsca, w którym występują na stronie WordPress
Gdzie w typowej witrynie na WordPressie pojawia się każde z dziesięciu ryzyk OWASP.
OWASP 2025Jak to wygląda w WordPressieCo sprawdzić najpierw
A01 Broken Access ControlEndpointy AJAX lub REST we wtyczkach bez sprawdzania uprawnień (capabilities) lub nonceRole i endpointy wtyczek
A02 Security MisconfigurationKomunikaty błędów na stronie produkcyjnej, otwarte listowanie katalogów, kopie zapasowe w katalogu głównym stronyUstawienia debugowania, konfiguracja serwera
A03 Software Supply Chain FailuresNieaktualne, porzucone lub pirackie („nulled”) wtyczki i motywyWykaz wtyczek
A04 Cryptographic FailuresBrak HTTPS na każdej podstronie, wyciek kluczy lub kopia wp-config.php do pobraniaHTTPS i sekrety
A05 InjectionSQL injection i cross-site scripting w kodzie wtyczek lub motywówPrzegląd kodu, aktualizacje
A06 Insecure DesignFunkcje, które ufają przeglądarce, np. cena przesyłana przez klientaPrzegląd projektu
A07 Authentication FailuresSłabe lub powtarzane hasła, brak drugiego składnika, nieograniczone próby logowania2FA, limity logowania
A08 Software or Data Integrity FailuresZmodyfikowane pliki rdzenia, wstrzyknięty kod, niebezpieczne unserialize()Sumy kontrolne
A09 Security Logging and Alerting FailuresBrak zapisów logowań, nowych administratorów czy zmian plikówDziennik aktywności
A10 Mishandling of Exceptional ConditionsBłę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() lub wp_verify_nonce() i nadać każdej trasie REST permission_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
Melike Görel

Melike Görel pisze poradniki secaudit.eu o bezpieczeństwie WordPressa i zgodności z przepisami UE dla AngelForce OÜ — firmy programistycznej z Tallinna, która stoi za secaudit.eu.

Przygotowano z pomocą AI i sprawdzono przed publikacją. Ten artykuł ma charakter ogólnoinformacyjny i nie stanowi porady prawnej.