# Walidacja i filtrowanie danych wejściowych w PHP za pomocą filter_var > Walidacja danych wejściowych w PHP z filter_var i filter_input_array: liczby, e-mail, URL, wartości logiczne, listy dozwolonych i granice. Z przykładami kodu. Źródło: https://phpsos.de/pl/blog/eingaben-validieren-php/ Stan: 25.10.2026 Dostawca: PHP SOS, Pomoc awaryjna PHP i bezpieczeństwo serwerów. Natychmiastowa pomoc przez WhatsApp: https://wa.me/491736494914?text=Dzie%C5%84%20dobry%2C%20PHP%20SOS%2C%20potrzebujemy%20pomocy%20z%20naszym%20serwerem%20PHP.%20Firma%3A%20%E2%80%A6%20Strona%20internetowa%3A%20%E2%80%A6 **Krótko:** Dane wejściowe w PHP walidujesz za pomocą `filter_var()` lub `filter_input_array()` i jasnych reguł dla każdego pola: typ, zakres, długość i dozwolone wartości. To, co nie pasuje, jest odrzucane, a nie po cichu przerabiane. Walidacja jest ważna dla czystych danych i mniejszej powierzchni ataku, ale nie zastępuje ani prepared statements przeciw SQL injection, ani kodowania zależnego od kontekstu przeciw XSS. ## Dlaczego „filtrować wszystko” nie jest koncepcją W wielu starszych projektach PHP na początku każdego pliku znajduje się pętla, która przepuszcza wszystkie wartości z `$_GET` i `$_POST` przez funkcję oczyszczającą. Daje to poczucie bezpieczeństwa. W praktyce raz usuwa za dużo, na przykład apostrofy w nazwiskach, a raz za mało, ponieważ ta sama funkcja ma jednocześnie obowiązywać dla SQL, HTML i nazw plików. Sensowna walidacja działa inaczej: dla każdego pola pyta, co jest tam dozwolone. Ilość w zamówieniu to liczba całkowita od 1 do górnej granicy. Pole sortowania to jedna z trzech stałych wartości. Data występuje w określonym formacie i jest po innej dacie. Wszystko inne jest odrzucane. OWASP rozróżnia tu dwa poziomy: kontrolę **składniową**, czy wartość ma właściwą formę, oraz kontrolę **semantyczną**, czy w danym kontekście ma sens. Obie należą do serwera; kontrole w przeglądarce służą wyłącznie wygodzie obsługi. ## Jakie filtry oferuje PHP Rozszerzenie filter jest w PHP domyślnie dołączone. Najważniejsze filtry walidacyjne według podręcznika PHP: | Filtr | Sprawdza | Ważne opcje i wskazówki | |---|---|---| | `FILTER_VALIDATE_INT` | liczba całkowita | `min_range`, `max_range` | | `FILTER_VALIDATE_FLOAT` | liczba z przecinkiem | `decimal` dla separatora | | `FILTER_VALIDATE_BOOL` | wartość logiczna | z `FILTER_NULL_ON_FAILURE` można odróżnić od „fałsz” | | `FILTER_VALIDATE_EMAIL` | forma adresu e-mail | nie dowodzi, że skrzynka istnieje | | `FILTER_VALIDATE_URL` | forma adresu URL | schemat sprawdzić samodzielnie, brak internacjonalizowanych domen | | `FILTER_VALIDATE_IP` | adres IP | flagi dla zakresów prywatnych i zarezerwowanych | | `FILTER_VALIDATE_REGEXP` | własny wzorzec | zakotwiczyć wzorzec za pomocą `^` i `$` | Filtr oczyszczający `FILTER_SANITIZE_STRING` jest od PHP 8.1 przestarzały. Kto jeszcze go używa, powinien przestawić walidację na odpowiednie filtry, a przy wyświetlaniu stosować `htmlspecialchars()`. ## filter_var w PHP: poprawne sprawdzanie formularza Za pomocą `filter_input_array()` można sprawdzić cały formularz w jednym kroku względem definicji. Nieznane pola nie są przy tym przejmowane: ```php ['filter' => FILTER_VALIDATE_INT, 'options' => ['min_range' => 1, 'max_range' => 50]], 'email' => FILTER_VALIDATE_EMAIL, 'agb' => ['filter' => FILTER_VALIDATE_BOOL, 'flags' => FILTER_NULL_ON_FAILURE], 'versand' => ['filter' => FILTER_VALIDATE_REGEXP, 'options' => ['regexp' => '/^(standard|express)$/']], ]; $daten = filter_input_array(INPUT_POST, $regeln) ?? []; $fehler = []; foreach ($regeln as $feld => $_) { if (!array_key_exists($feld, $daten) || $daten[$feld] === false || $daten[$feld] === null) { $fehler[] = $feld; } } if ($fehler !== []) { http_response_code(422); // Wyświetlić komunikat o błędzie dla każdego pola, nie przetwarzać danych wejściowych } ``` Zwróć uwagę na ścisłe porównania za pomocą `===`: prawidłowa wartość `0` lub pusty ciąg nie mogą być mylone z niepowodzeniem. Dlaczego luźne porównania są tu niebezpieczne, wyjaśnia artykuł [Type juggling: luźne porównania jako ryzyko bezpieczeństwa](https://phpsos.de/pl/blog/type-juggling-php/). Jak PHP w ogóle udostępnia dane żądania, opisuje artykuł [Superglobals: $_GET, $_POST, $_FILES i inne](https://phpsos.de/pl/php/superglobals/). ## Pułapki przy e-mailu, URL i tekstach swobodnych Niektóre filtry robią mniej, niż sugeruje ich nazwa: 1. **Adresy URL:** `FILTER_VALIDATE_URL` akceptuje także inne schematy niż http i https. Sprawdź potem schemat za pomocą `parse_url()` względem stałej listy. Jeśli adres URL jest pobierany przez serwer, obowiązują dodatkowe reguły, zob. [Zapobieganie Server-Side Request Forgery w PHP](https://phpsos.de/pl/blog/ssrf-in-php/). 2. **Adresy e-mail:** Filtr sprawdza formę, a nie posiadanie. Kto musi mieć pewność, wysyła link potwierdzający. 3. **Tekst swobodny:** Imion, wiadomości i adresów prawie nie da się sensownie ograniczyć do znaków. Sprawdzaj długość i kodowanie znaków, na przykład za pomocą `mb_check_encoding($wert, 'UTF-8')`, a przy wyświetlaniu polegaj na kodowaniu. 4. **Wyrażenia regularne:** Bez `^` i `$` wzorzec sprawdza tylko, czy występuje gdzieś w tekście, a nie czy pasuje cała wartość. 5. **Tablice zamiast ciągów:** Atakujący może zamiast tekstu wysłać tablicę. Bez kontroli typu prowadzi to do ostrzeżeń lub nieoczekiwanego zachowania. > **Wskazówka:** > Dla stałych wartości wyboru, takich jak sortowanie, język czy sposób wysyłki, lista dozwolonych z `in_array($wert, $erlaubt, true)` lub wyrażeniem `match` jest prostsza i ostrzejsza niż każde wyrażenie regularne. Kolejny częsty błąd dotyczy liczb o znaczeniu, takich jak ceny, ilości czy rabaty. To, że wartość jest prawidłową liczbą, nic nie mówi o tym, czy jest dozwolona w danym kontekście. Ujemna ilość, rabat przewyższający wartość towaru albo cena przejęta z formularza zamiast z bazy danych to klasyczne błędy logiki. Ceny, uprawnienia i wartości statusów należą więc zawsze na serwer, a nigdy do ukrytych pól formularza. ## JSON, webhooki i importy: walidacja poza formularzami Wiele wejść to dziś nie formularze, lecz żądania JSON z aplikacji, webhooki z usług płatniczych albo pliki importowe od dostawców. Także tam obowiązuje: najpierw bezpiecznie wczytać, potem sprawdzić. OWASP radzi ograniczać rozmiar i głębokość zagnieżdżenia, zanim dane w ogóle zostaną wczytane. W PHP część tego przejmuje `json_decode()` z maksymalną głębokością i `JSON_THROW_ON_ERROR`: ```php