sanityzacja danych wejściowych

Sanityzacja danych wejściowych to oczyszczanie i filtrowanie danych przyjmowanych od użytkownika do dopuszczalnej postaci w chwili ich wczytania, zanim trafią do bazy lub logiki aplikacji. Dokumentacja WordPressa definiuje ją jako proces zabezpieczania, czyszczenia i filtrowania danych wejściowych ^[1]. Sanityzacja nie odrzuca danych, tylko je przekształca: usuwa znaczniki, zbędne znaki czy nieprawidłowe sekwencje. Jest jedną z trzech warstw obsługi danych, obok walidacji na wejściu i escapowania na wyjściu.

Jak działa

Dane z zewnątrz przechodzą przez kilka etapów, z których każdy robi coś innego. Walidacja według dokumentacji WordPressa to sprawdzenie danych względem wzorca z jednoznacznym wynikiem: poprawne albo niepoprawne ^[2]. Sanityzacja przekształca dane do bezpiecznej postaci. Escapowanie zabezpiecza dane wyjściowe przez usuwanie niechcianych elementów, takich jak zniekształcony HTML albo znaczniki skryptów ^[3], i powinno odbywać się jak najpóźniej, najlepiej w chwili wypisania ^[3].

RYS. 1Droga danych przez aplikację

WordPress wskazuje, że walidacja jest preferowana wobec sanityzacji, bo jest bardziej precyzyjna ^[1]. Sanityzację stosuje się tam, gdzie nie da się określić dokładnego zbioru poprawnych wartości, na przykład w polu tytułu czy komentarza.

MITRE zwraca uwagę na kolejność operacji: dane należy zdekodować i sprowadzić do postaci kanonicznej, zanim zostaną sprawdzone, i uważać, by nie dekodować ich dwukrotnie ^[5]. Inaczej zakodowany ładunek przejdzie przez filtr, a zostanie odkodowany dopiero dalej.

OWASP rozróżnia dwa poziomy sprawdzania. Walidacja składniowa pilnuje formatu, na przykład daty albo kwoty; walidacja semantyczna sprawdza sens wartości w kontekście, na przykład czy data początkowa poprzedza końcową albo czy cena mieści się w zakresie ^[4]. MITRE wymienia cechy, które warto sprawdzać: wielkości takie jak rozmiar, długość czy częstotliwość, poprawność składni, typ danych oraz spójność między elementami ^[5]. Sanityzacja uzupełnia te kontrole tam, gdzie wartość ma być przyjęta, ale w oczyszczonej postaci.

Rodzaje

Sposób czyszczenia zależy od typu danych. WordPress udostępnia osobne funkcje do adresów e-mail, nazw plików, adresów URL, tekstu, tytułów, nazw użytkowników, kolorów i klas HTML ^[1].

Funkcja sanitize_text_field() sprawdza poprawność UTF-8, zamienia pojedyncze znaki „mniejsze niż” na encje, usuwa wszystkie znaczniki, podziały linii, tabulatory i nadmiarowe spacje oraz usuwa oktety ^[1].

Równolegle do wyboru funkcji istnieje wybór strategii. Dokumentacja WordPressa zaleca listę dozwolonych wartości, czyli przyjmowanie danych tylko ze skończonego zbioru znanych i zaufanych wartości; lista zakazanych wartości „bardzo rzadko jest dobrym pomysłem” ^[2]. OWASP wyjaśnia, że listę zakazów łatwo obejść, a przy okazji blokuje ona poprawne dane, na przykład nazwisko z apostrofem ^[4].

W WordPressie

Typowy wzorzec w kodzie wtyczki wygląda tak: dane z $_POST są czyszczone funkcją dobraną do typu, zapisywane, a przy wypisaniu kodowane dla kontekstu.

$title = sanitize_text_field( wp_unslash( $_POST['title'] ?? '' ) );
update_post_meta( $post_id, 'title', $title );
// przy wyświetlaniu:
echo esc_html( get_post_meta( $post_id, 'title', true ) );

Dokumentacja podkreśla, że niezaufane dane pochodzą z wielu źródeł: od użytkowników, z zewnętrznych serwisów, a nawet z własnej bazy danych, i wszystkie trzeba sprawdzić przed użyciem ^[2]. Dotyczy to także danych od administratorów ^[1]. Sprawdzenie typu danych nie zastępuje jednak weryfikacji uprawnień ani tokenu nonce: sanityzacja mówi, jaką postać mają dane, a nie, czy dany użytkownik może je zapisać.

Sekurak opisuje scenariusz typowy dla wtyczek: dane wprowadzone w formularzu zostają zapisane w pliku, a następnie wyświetlone bez sanityzacji w panelu administracyjnym ^[7]. Tak powstaje Stored XSS wymierzony w administratora. Takie błędy we wtyczkach opisuje hasło podatność we wtyczce.

Zagrożenia i skutki

Brak lub błąd sanityzacji i walidacji MITRE opisuje jako CWE-20: produkt przyjmuje dane, ale nie sprawdza albo źle sprawdza, czy mają właściwości potrzebne do bezpiecznego przetworzenia ^[5]. Słabość ta pojawia się w zestawieniach CWE Top 25 z kolejnych lat, od 2019 do 2025 roku ^[5]. Z niedostatecznej obsługi danych wejściowych wynikają:

• SQL injection, gdy dane trafiają do zapytania do bazy,
• XSS (Cross-Site Scripting), gdy trafiają na stronę bez kodowania,
• wstrzyknięcie poleceń (command injection), gdy trafiają do powłoki systemu,
• path traversal, gdy służą do budowy ścieżki pliku.

Jak się bronić

Podstawowa zasada OWASP: walidacja wejścia nie powinna być głównym sposobem zapobiegania XSS, SQL injection i podobnym atakom, choć dobrze wdrożona znacząco ogranicza ich skutki ^[4]. Główną obroną pozostaje technika właściwa dla miejsca użycia danych: zapytanie parametryzowane dla bazy i escapowanie dla HTML.

• Po stronie serwera. OWASP wymaga walidacji na serwerze, bo sprawdzenie w JavaScripcie w przeglądarce atakujący obejdzie, wyłączając skrypty albo używając pośredniczącego proxy ^[4].
• Jak najwcześniej. Dane sprawdza się zaraz po odebraniu od strony zewnętrznej ^[4].
• Najpierw walidacja, potem sanityzacja. Zgodnie z dokumentacją WordPressa ^[1].
• Lista dozwolonych wartości zamiast listy zakazów ^{[2] [4]}.
• Biblioteka do HTML. Do bogatej treści OWASP odsyła do sprawdzonych bibliotek oczyszczających HTML zamiast własnych filtrów ^[4]; w WordPressie tę rolę pełni wp_kses() ^[1].

Historia i przykłady

CERT Polska 29 lipca 2026 roku opisał podatność CVE-2026-33385 w systemie Quick.CMS firmy OpenSolution. Niewłaściwa sanityzacja danych od uprzywilejowanych użytkowników w wielu polach panelu administracyjnego umożliwiała blind SQL injection ^[6]. Dotyczyło to wersji 6.8, a producent odmówił poprawki, argumentując, że panel i tak pozwala na daleko idące zmiany ^[6]. Przykład pokazuje, że dane od administratora również wymagają czyszczenia, co podkreśla dokumentacja WordPressa ^[1].