Bezpieczny kod WordPressa — co sprawdzić na wejściu, co zakodować na wyjściu, kogo wpuścić.

WordPress nie wydaje dokumentu pod nazwą „Secure Coding Standard”. Standardem w praktyce są dwie rzeczy: rozdział Security podręcznika dla programistów (pięć zasad i funkcje rdzenia do walidacji, sanityzacji, escapowania, nonce i uprawnień) oraz WordPress Coding Standards — reguły, które te zasady sprawdzają w kodzie automatycznie. Kierunek jest jeden: dane wchodzące się waliduje albo sanityzuje, dane wychodzące na stronę się escapuje — w chwili wypisania i pod kontekst. Poniżej cały standard, próba tego, co automat łapie, a czego nie, i luki WordPressa rozłożone na reguły, których zabrakło.

Źródło: podręcznik Security (Common APIs, akt. 23.07.2026) z podstronami, $wpdb->prepare(), standard PHP, WPCS 3.4.1 (27.07.2026, MIT), Plugin Check, odczyt 26.09.2026. Opisy są naszym opracowaniem, nie tłumaczeniem. Dane WordPressa: feed Wordfence, stan 07.09.2026; przypisanie luk do reguł jest nasze. Pozostałe standardy serii: OWASP Top 10, ECS, CVSS (średnie wyniki w TAB. 11).

Zasady

5+ 3 zasady postawy

Reguły WPCS Security + DB

11WPCS 3.4.1

Luki WP z regułą standardu

93,6 %37 221 z 39 748

Bramka Creato Ping

0 / 0błędów / ostrzeżeń · 5 wyjątków z powodem

Najczęstsza pomyłka to zamiana ról: sanitize_text_field() nie jest escapowaniem, a esc_html() nie jest walidacją. sanitize_text_field() robi pięć rzeczy: sprawdza, czy tekst jest poprawnym UTF-8; pojedynczy < zamienia na encję; usuwa wszystkie znaczniki; usuwa podziały linii, tabulatory i nadmiarowe spacje; usuwa oktety (%xx) — ale nie wie, gdzie tekst zostanie wypisany.

„Escapuj późno”: najlepiej w tej samej linii co echo. Wtedy recenzja jednej linii wystarcza, żeby powiedzieć, czy wypisanie jest bezpieczne.

To reguła, której automat nie sprawdza (TAB. 10), a w feedzie brak uprawnień to 7559 luk — w 2026 roku więcej niż XSS (TAB. 11).

Core = WordPress-Core, Extra = WordPress-Extra (zawiera Core), pełny = tylko zestaw „WordPress” albo wskazanie reguły wprost — tak robi bramka LAB247, która włącza całe przestrzenie WordPress.Security i WordPress.DB niezależnie od zestawów.

zly.php — wszystko naraz:

<?php
function zly_zapis() {
	global $wpdb;
	$id = $_GET['id'];
	echo '<p>' . $_POST['imie'] . '</p>';
	$wpdb->query( "DELETE FROM {$wpdb->posts} WHERE ID = $id" );
	update_option( 'x', $_POST['x'] );
	wp_redirect( $_GET['wroc'] );
	$dane = unserialize( $_COOKIE['d'] );
	eval( $_REQUEST['kod'] );
}

dobry.php — ta sama robota według standardu (uprawnienie → nonce → isset/unslash/sanityzacja → escapowanie → prepare → bezpieczne przekierowanie):

<?php
function dobry_zapis() {
	global $wpdb;
	if ( ! current_user_can( 'manage_options' ) ) {
		return;
	}
	check_admin_referer( 'dobry_zapis' );
	$id = isset( $_POST['id'] ) ? absint( $_POST['id'] ) : 0;
	$imie = isset( $_POST['imie'] ) ? sanitize_text_field( wp_unslash( $_POST['imie'] ) ) : '';
	echo '<p>' . esc_html( $imie ) . '</p>';
	$wpdb->query( $wpdb->prepare( "DELETE FROM {$wpdb->posts} WHERE ID = %d", $id ) );
	wp_safe_redirect( admin_url() );
	exit;
}

luki.php — dwie prawdziwe luki, które przechodzą (gość kasuje wpisy; esc_html() w href), i jedna pomyłka ról, którą automat łapie:

<?php
add_action( 'wp_ajax_nopriv_usun', 'luki_usun' );
function luki_usun() {
	check_ajax_referer( 'usun' );
	$id = isset( $_POST['id'] ) ? absint( $_POST['id'] ) : 0;
	wp_delete_post( $id, true );
}
function luki_link( $url ) {
	echo '<a href="' . esc_html( $url ) . '">x</a>';
}
function luki_wyjscie() {
	echo sanitize_text_field( get_option( 'x' ) );
}

Zestaw reguł próby (plus nagłówek <ruleset>):

<rule ref="WordPress.Security"/>
<rule ref="WordPress.DB"/>
<rule ref="WordPress.PHP.DiscouragedPHPFunctions"/>
<rule ref="Squiz.PHP.Eval"/>

Bez logow. = wektor CVSS z PR:N (atak bez konta). Bez łatki = przynajmniej jeden komponent wpisu bez wersji naprawiającej. * 2026 = od stycznia do 07.09.2026. W 2026 brak uprawnień (2204) pierwszy raz wyprzedził XSS (1985) — a to jedyna duża grupa, na którą WPCS nie ma reguły. Liczy się data publikacji wpisu w feedzie, nie data powstania luki.

Wtyczka 0.13.0-alfa.2: jeden plik, 1558 linii PHP. Bramka chroni to, co wtyczka robi u klienta; luki cudzych wtyczek śledzimy w Podatnościach i w Rozszerzeniach.

Nazwa

„WordPress Core Secure Coding Standards” nie jest tytułem żadnego dokumentu WordPressa. Opisujemy rozdział Security podręcznika Common APIs i reguły Security/DB z WPCS — to one są tym standardem w praktyce.

Grupowanie CWE

Nasze, nie WordPressa: każdej luce z feedu przypisaliśmy regułę standardu, która ją zatrzymuje (lista CWE w TAB. 11). Uwierzytelnianie (CWE-287, 288, 306) celowo w „inne” — current_user_can() go nie naprawia.

Feed

Odpis feedu Wordfence Intelligence używany przez monitoring LAB247, 39 748 wpisów, ostatni z 07.09.2026. Rok = data publikacji wpisu; 2026 to niepełne 8 miesięcy.

Próba bramki

Trzy pliki z TAB. 10 sprawdzone PHPCS 3.13.6 + WPCS 3.4.1 z zestawem pokazanym obok; liczby to wynik raportu `--report=full`. Próba jest nasza — do powtórzenia jedną komendą.

Wtyczka

Creato Ping 0.13.0-alfa.2, jeden plik PHP (1 558 linii). Bramka i pełny zestaw WordPress uruchomione 26.09.2026.