WPCS

WPCS (WordPress Coding Standards) to zbiór reguł dla narzędzia PHP_CodeSniffer, które sprawdzają kod pisany dla WordPressa pod kątem jakości i zgodności z konwencjami, zwłaszcza z oficjalnymi standardami kodowania WordPressa ^[1]. Podręcznik standardów PHP wskazuje ten zestaw jako oficjalne narzędzie do automatycznej kontroli zgodności ^[2]. Poza regułami stylu WPCS zawiera reguły bezpieczeństwa: wykrywa niezakodowane wyjście, brak weryfikacji nonce i zapytania SQL składane bez przygotowania ^{[4] [3]}. Dzięki temu część typowych błędów wtyczek i motywów można znaleźć przed wdrożeniem.

Jak działa

PHP_CodeSniffer czyta pliki PHP i sprawdza je zestawem reguł zwanych „sniffami”. WPCS dostarcza takie reguły dla WordPressa ^[1]. Instalacja odbywa się przez Composer, a wynikiem uruchomienia jest raport błędów i ostrzeżeń ^[1]:

composer require --dev wp-coding-standards/wpcs:"^3.0"
vendor/bin/phpcs --standard=WordPress wp-load.php

Projekt wymaga PHP w wersji 7.2 lub nowszej ^[1]. Typowe miejsce użycia pokazuje schemat poniżej.

RYS. 1WPCS w procesie wydawniczym

Reguła nie rozumie intencji programisty. Zgłasza wzorce, które wyglądają na ryzykowne, na przykład użycie danych z tablicy $_POST przed sprawdzeniem nonce. Programista może świadomie wyłączyć zgłoszenie w danym miejscu, co projekt opisuje na stronach wiki ^[1].

Odmiany

WPCS udostępnia cztery zestawy reguł ^[1]. Różnią się zakresem, a więc także tym, ile reguł bezpieczeństwa uruchamiają.

W kategorii bezpieczeństwa WPCS ma pięć reguł: EscapeOutput, NonceVerification, PluginMenuSlug, SafeRedirect i ValidatedSanitizedInput ^[5]. Zestaw WordPress-Core sprawdza zapytania do bazy regułami PreparedSQL i PreparedSQLPlaceholders ^[3].

W WordPressie

Każda reguła bezpieczeństwa odpowiada jednej zasadzie z podręcznika bezpieczeństwa WordPressa, który każe nie ufać żadnym danym, walidować i czyścić wejście oraz kodować wyjście ^[7].

• EscapeOutput pilnuje escapowania danych wypisywanych na stronie ^[4], czyli obrony przed XSS (Cross-Site Scripting). Podręcznik zaleca kodowanie jak najpóźniej ^[7].
• NonceVerification sprawdza, czy przed użyciem wartości z tablic superglobalnych wykonano weryfikację nonce ^[4]. Brak takiej weryfikacji to typowa przyczyna podatności CSRF (Cross-Site Request Forgery).
• SafeRedirect zachęca do wp_safe_redirect(), aby uniknąć podatności open redirect ^[4].
• ValidatedSanitizedInput dotyczy sanityzacji danych wejściowych ^[5].
• PreparedSQL wymaga escapowania jak najbliżej zapytania, najlepiej przez $wpdb->prepare() ^[3]. To odpowiednik zapytania parametryzowanego, chroniący przed SQL injection. Podręcznik PHP wymienia symbole zastępcze %d, %f, %s i %i ^[2].

Zestaw Extra zawiera też regułę WordPress.WP.Capabilities, która sprawdza, czy uprawnienia są używane poprawnie ^[4]. Reguła ocenia jednak wywołania, które w kodzie są. Brakującej weryfikacji uprawnień w procedurze AJAX nie ma czego ocenić, dlatego przegląd kodu pozostaje potrzebny.

Pokrewnym narzędziem jest Plugin Check, który sprawdza, czy wtyczka spełnia wymagania katalogu WordPress.org, w tym dobre praktyki bezpieczeństwa ^[8]. Korzysta ono z PHP_CodeSniffer i działa także z wiersza poleceń jako wp plugin check ^[8]. Autorzy zaznaczają, że nie zastępuje ono ręcznego przeglądu ^[8].

Znaczenie

Część podatności we wtyczkach i podatności w motywach wynika z wzorców, które WPCS potrafi wskazać automatycznie: niezakodowanego wyjścia, niesprawdzonego nonce, zapytania SQL sklejonego z danymi użytkownika. Standardy są obowiązkowe dla rdzenia WordPressa, a dla wtyczek i motywów zdecydowanie zalecane, szczególnie w części dotyczącej bezpieczeństwa ^[2].

Zielony raport nie dowodzi jednak braku podatności. Analiza statyczna nie widzi logiki biznesowej ani tego, czy dane pochodzą z zaufanego źródła. Gdy programista oznaczy zgłoszenie jako wyjątek, reguła przestaje o nim przypominać.

Dobre praktyki

• Uruchamiać WPCS przy każdej zmianie, najlepiej automatycznie w potoku CI, a nie jednorazowo przed wydaniem.
• Do kodu, który trafia na produkcję, używać zestawu WordPress-Extra albo pełnego WordPress; sam Core nie zawiera reguł escapowania ani nonce ^{[3] [4]}.
• Każde wyłączenie reguły w kodzie opatrywać komentarzem z uzasadnieniem, żeby recenzent mógł je ocenić.
• Utrzymywać aktualną wersję WPCS, bo samo narzędzie też może mieć błędy bezpieczeństwa.
• Nie uruchamiać skanera na niezaufanym kodzie z uprawnieniami, które dają dostęp do sekretów potoku.

Historia i przykłady

27 lipca 2026 roku opublikowano wydanie 3.4.1, oznaczone jako wydanie bezpieczeństwa z identyfikatorem GHSA-3pwp-g2mj-5p3v ^[6]. Błąd w regule WordPress.WP.EnqueuedResourceParameters mógł prowadzić do wykonania dowolnych poleceń na maszynie, która skanuje niezaufany kod, np. w potoku CI albo podczas przeglądu kodu ^[6]. Dotyczył zestawów WordPress i WordPress-Extra, a nie WordPress-Core ani WordPress-Docs ^[6]. Przypadek pokazuje, że narzędzie kontroli jakości jest częścią łańcucha dostaw i może stać się celem ataku na potok CI/CD (CI/CD pipeline compromise), którego skutkiem jest zdalne wykonanie kodu (RCE).