SQL Injection i XSS: praktyczna ochrona formularzy, panelu i API

SQL Injection i XSS to dwa różne problemy, ale w praktyce psują ten sam element strony: zaufanie do danych od użytkownika. Jeżeli formularz, wyszukiwarka, parametr URL albo panel administracyjny przyjmują dane bez jasnych zasad walidacji, łatwo o wyciek, przejęcie sesji albo uszkodzenie bazy.

Dobra ochrona nie polega na jednej wtyczce. Potrzebny jest prosty zestaw zasad: parametryzowane zapytania, walidacja danych wejściowych, escapowanie danych wyjściowych, ograniczone uprawnienia i regularne testy. To dotyczy zarówno WordPressa, jak i aplikacji pisanych w Next.js, PHP, Laravelu czy Node.

Najkrótsza różnica: gdzie pojawia się ryzyko?

Zagrożenie	Najczęstsze miejsce	Co może się stać	Pierwsza linia obrony
SQL Injection	formularze, filtry, wyszukiwarki, endpointy API	odczyt lub zmiana danych w bazie	prepared statements i ORM bez ręcznego składania SQL
XSS reflected	parametry URL, wyniki wyszukiwania, komunikaty błędów	wykonanie kodu JS w przeglądarce użytkownika	escapowanie HTML i walidacja wejścia
XSS stored	komentarze, opisy produktów, pola profilu	złośliwy kod zapisany w bazie i wyświetlany wielu osobom	sanityzacja HTML oraz whitelist dozwolonych znaczników
DOM XSS	frontend, który wkłada dane do DOM	atak bez udziału backendu	bezpieczne API DOM i unikanie innerHTML

Checklist przed publikacją formularza

• Zdefiniuj typ danych. E-mail ma być e-mailem, numer telefonu numerem, a pole wiadomości tekstem o maksymalnej długości.
• Nie sklejaj zapytań SQL ze stringów. Użyj parametrów, ORM albo warstwy query buildera.
• Escapuj dane przy wyświetlaniu. Dane bezpieczne w bazie nie są automatycznie bezpieczne w HTML.
• Ustaw limity. Długość pól, liczba prób, rozmiar payloadu i throttling chronią też przed spamem.
• Oddziel role. Konto aplikacji nie powinno mieć uprawnień administratora bazy.
• Loguj anomalie. Powtarzalne znaki typu ' OR 1=1, tagi <script> albo zakodowany HTML to sygnał do blokady.

Przykład: bezpieczny wzorzec dla zapytań

Nie chodzi o konkretny framework, tylko o zasadę: dane użytkownika trafiają do parametru, a nie do treści zapytania.

-- Źle: składanie SQL ręcznie
SELECT * FROM users WHERE email = '${email}';

-- Dobrze: parametr obsługiwany przez bibliotekę
SELECT * FROM users WHERE email = ?;

XSS: największy problem jest przy wyświetlaniu treści

Wielu właścicieli stron myśli, że jeśli formularz zapisuje dane poprawnie, to problem znika. Nie. XSS pojawia się wtedy, gdy aplikacja wyświetla treść w HTML, a przeglądarka interpretuje ją jako kod. Dlatego opisy, komentarze i pola administracyjne powinny przechodzić przez escapowanie albo kontrolowaną sanityzację.

Minimum nagłówków bezpieczeństwa

• Content-Security-Policy ogranicza źródła skryptów i zasobów.
• X-Content-Type-Options: nosniff zmniejsza ryzyko błędnej interpretacji plików.
• Referrer-Policy ogranicza przekazywanie danych w nagłówku referer.
• HttpOnly i Secure dla cookies utrudniają kradzież sesji przez JavaScript.

Jak testować bez przesady

1. Sprawdź wszystkie formularze i endpointy, nie tylko kontakt.
2. Przetestuj payloady w polach tekstowych, parametrach URL i wyszukiwarce.
3. Zweryfikuj, czy błędy nie ujawniają zapytań SQL, ścieżek plików ani stack trace.
4. Po każdej większej zmianie uruchom prosty skan i ręczny smoke test najważniejszych ścieżek.

FAQ

Czy WordPress chroni przed SQL Injection i XSS automatycznie?

Rdzeń WordPressa ma dobre mechanizmy, ale ryzyko często pochodzi z wtyczek, motywów, własnych shortcode’ów i formularzy. Każdy niestandardowy kod trzeba traktować osobno.

Czy sama zapora WAF wystarczy?

Nie. WAF pomaga zatrzymać część ataków, ale nie zastępuje poprawnego kodu. Najbezpieczniej traktować WAF jako dodatkową warstwę, nie fundament.

Co sprawdzić po migracji strony?

Formularze, endpointy API, panel CMS, nagłówki bezpieczeństwa, cookies oraz miejsca, gdzie treści użytkowników są wyświetlane w HTML.