Co to jest WAF? Jak działa Web Application Firewall i kiedy go potrzebujesz

WAF (Web Application Firewall) to zapora aplikacji internetowych, która analizuje ruch HTTP i HTTPS między użytkownikami a stroną lub API i blokuje żądania wyglądające na atak — np. próby SQL injection, Cross Site Scripting czy odczytu plików systemowych. W odróżnieniu od klasycznego firewalla nie patrzy tylko na adresy i porty, ale na treść żądań: adresy URL, parametry, nagłówki, ciasteczka i dane z formularzy.

WAF działa jako pośrednik (reverse proxy) przed aplikacją, jako moduł serwera WWW albo usługa w chmurze. Nie zastąpi bezpiecznego kodu i aktualizacji, ale skutecznie odcina masowe, zautomatyzowane ataki i daje czas na załatanie luk. Poniżej wyjaśniamy, jak działa, jakie są rodzaje WAF, jak go wdrożyć i czego się po nim nie spodziewać.

Jak działa Web Application Firewall

Każde żądanie przechodzi przez WAF, zanim dotrze do aplikacji. WAF rozkłada je na części (metoda, ścieżka, parametry GET i POST, nagłówki, ciasteczka, treść JSON lub XML), normalizuje (dekoduje URL, Base64, usuwa sztuczki z wielkością liter) i porównuje z regułami. Na podstawie wyniku żądanie zostaje przepuszczone, zablokowane (zwykle z kodem 403), poddane wyzwaniu (np. CAPTCHA lub test JavaScript dla botów) albo tylko zapisane w logu.

Stosuje się dwa modele bezpieczeństwa:

W praktyce większość wdrożeń łączy oba podejścia: gotowy zestaw reguł wykrywających ataki plus reguły pozytywne dla najważniejszych elementów, np. API z dobrze opisanym schematem. Nowocześniejsze produkty dodają analizę zachowania (wykrywanie botów, nietypowej liczby żądań) i modele uczenia maszynowego.

Tryb anomalii i poziomy czułości

Popularny otwarty zestaw reguł OWASP Core Rule Set (CRS) nie blokuje żądania po pierwszym trafieniu. Każda pasująca reguła dodaje punkty do wyniku anomalii, a żądanie jest blokowane dopiero po przekroczeniu progu. Czułość reguł ustawia się poziomami paranoi (paranoia level) od 1 do 4 — im wyższy, tym więcej wykrytych ataków, ale też więcej fałszywych alarmów.

Przed czym chroni WAF

WAF jest projektowany przede wszystkim pod zagrożenia z listy OWASP Top 10:

• SQL injection — wstrzyknięcie kodu SQL w parametr, np. ?id=1' OR '1'='1,
• Cross Site Scripting (XSS) — wstrzyknięcie skryptu, który wykona się w przeglądarce innego użytkownika; mechanizm opisaliśmy w tekście o atakach XSS,
• path traversal i local file inclusion — próby odczytu plików typu ../../etc/passwd,
• wstrzykiwanie poleceń systemowych (command injection) i zdalne wykonanie kodu,
• SSRF — zmuszanie serwera do wysyłania żądań do wewnętrznych zasobów,
• skanowanie i boty — automatyczne wyszukiwanie paneli administracyjnych, plików kopii zapasowych i znanych luk,
• nadużycia formularzy logowania — credential stuffing i zgadywanie haseł, ograniczane limitami żądań,
• ataki DDoS w warstwie aplikacji — zalewanie kosztownych endpointów żądaniami; o obronie przed DDoS w szerszym ujęciu przeczytasz w artykule Ataki DDoS i jak im zapobiegać.

Bardzo praktyczną funkcją jest tzw. wirtualne łatanie (virtual patching). Gdy w używanej wtyczce lub bibliotece zostanie ujawniona luka, dostawca WAF lub administrator dodaje regułę blokującą jej wykorzystanie, zanim aplikacja zostanie zaktualizowana.

WAF a firewall, NGFW i IPS — czym się różnią

NGFW również potrafi rozpoznawać ataki webowe, ale nie zna kontekstu aplikacji tak dokładnie jak WAF. Różnice między zaporami opisaliśmy szerzej w artykule Firewall, NGFW i UTM — różnice, a systemom wykrywania włamań poświęciliśmy tekst Co to jest IDS.

Rodzaje WAF: chmura, serwer, urządzenie

WAF w chmurze

Ruch do domeny kierowany jest (zwykle przez zmianę rekordów DNS) do dostawcy, który filtruje go i przekazuje do Twojego serwera. Przykłady: Cloudflare WAF, AWS WAF (z CloudFront lub Application Load Balancer), Azure Web Application Firewall (na Application Gateway lub Front Door), Google Cloud Armor, Akamai, Imperva. Często WAF jest częścią usługi CDN.

Plusy: szybkie wdrożenie, gotowe i aktualizowane reguły, ochrona przed DDoS na krawędzi sieci. Minusy: ruch (także odszyfrowany) przechodzi przez infrastrukturę dostawcy, a koszty rosną z liczbą żądań i funkcji.

Ważne: WAF w chmurze chroni tylko ruch, który przez niego przechodzi. Jeśli atakujący pozna prawdziwy adres IP serwera, ominie zaporę i połączy się bezpośrednio. Skonfiguruj zaporę serwera tak, by przyjmowała ruch HTTP/HTTPS wyłącznie z adresów dostawcy WAF.

WAF na serwerze (host-based)

Moduł działający w serwerze WWW lub przed nim na tym samym hoście. Najpopularniejsze otwarte rozwiązania to ModSecurity (od 2024 r. rozwijany pod skrzydłami OWASP) i Coraza — oba korzystają z OWASP CRS. W świecie WordPressa podobną rolę pełnią wtyczki działające na poziomie aplikacji, np. Wordfence.

Plusy: pełna kontrola, brak opłat licencyjnych, dane nie opuszczają serwera. Minusy: obciąża serwer, wymaga wiedzy przy strojeniu reguł i nie chroni przed atakami, które wysycą łącze.

WAF sprzętowy lub wirtualny (network-based)

Dedykowane urządzenie lub maszyna wirtualna w centrum danych, np. F5 BIG-IP Advanced WAF czy FortiWeb, często połączone z równoważeniem obciążenia. Spotykane w dużych organizacjach z własną infrastrukturą. Plusy: wydajność, niskie opóźnienia, pełna kontrola. Minusy: koszt, utrzymanie i potrzeba specjalistów.

Jak wdrożyć WAF krok po kroku

1. Zinwentaryzuj aplikacje. Spisz domeny, subdomeny, API i panele administracyjne, które mają być chronione.
2. Wybierz model wdrożenia. Dla małej strony zwykle najprostszy jest WAF w chmurze; dla serwera, nad którym masz pełną kontrolę — ModSecurity lub Coraza z CRS.
3. Uruchom tryb wykrywania. Przez co najmniej kilka dni WAF tylko loguje to, co by zablokował.
4. Przeanalizuj fałszywe alarmy. Typowe źródła: edytory treści w panelu CMS, pola z kodem HTML, duże formularze, nietypowe API.
5. Dodaj wyjątki punktowo. Wyłączaj konkretne reguły dla konkretnych ścieżek lub parametrów, a nie cały WAF.
6. Włącz blokowanie i ustaw powiadomienia o nietypowym wzroście blokad.
7. Dodaj reguły specyficzne dla aplikacji: limity żądań na logowanie i API, ograniczenie dostępu do paneli administracyjnych, blokadę nieużywanych metod HTTP.
8. Testuj regularnie. WAF warto uwzględnić w testach bezpieczeństwa, bo reguły, które działały rok temu, mogą przepuszczać nowe techniki.

Przykład: ModSecurity z OWASP CRS na Apache (Debian/Ubuntu)

sudo apt install libapache2-mod-security2
sudo cp /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf
sudo systemctl restart apache2

W pliku /etc/modsecurity/modsecurity.conf domyślnie ustawione jest SecRuleEngine DetectionOnly, czyli tryb wykrywania. Po okresie obserwacji logów zmień je na SecRuleEngine On. Własne reguły i wyjątki dodasz w osobnym pliku konfiguracyjnym:

# dostęp do wp-login.php tylko z sieci biurowej
SecRule REQUEST_URI "@beginsWith /wp-login.php" \
    "id:1000001,phase:1,deny,status:403,msg:'Logowanie tylko z biura',chain"
    SecRule REMOTE_ADDR "!@ipMatch 203.0.113.0/24"

# wyjątek: wyłączenie jednej reguły XSS tylko dla edytora wpisów
SecRule REQUEST_URI "@beginsWith /wp-admin/post.php" \
    "id:1000010,phase:1,pass,nolog,ctl:ruleRemoveById=941100"

Prosty test, czy WAF blokuje oczywisty atak (na własnej stronie):

curl -s -o /dev/null -w "%{http_code}\n" "https://example.com/?id=1%27%20OR%20%271%27=%271"

Wynik 403 oznacza, że reguła zadziałała. W trybie wykrywania dostaniesz 200, a wpis pojawi się w logu audytu.

Ograniczenia WAF — czego nie załatwi

• Błędy logiki biznesowej. WAF nie wie, że użytkownik A nie powinien widzieć faktury użytkownika B pod adresem /faktura/1235. Takie luki (np. IDOR) trzeba naprawić w kodzie.
• Obejścia reguł. Atakujący stosują kodowanie, fragmentację i nietypowe składnie, by ominąć wzorce. Żaden zestaw reguł nie jest szczelny.
• Fałszywe alarmy. Zbyt agresywne reguły blokują prawdziwych klientów — np. przy wklejaniu kodu w formularz kontaktowy.
• Ruch szyfrowany. Aby analizować HTTPS, WAF musi terminować TLS, czyli mieć certyfikat i klucz prywatny lub działać jako proxy dostawcy.
• Luki po stronie klienta i zainfekowane wtyczki. Jeśli złośliwy kod jest już w aplikacji, WAF zwykle go nie usunie.

Dlatego WAF traktuj jako jedną z warstw obrony: obok aktualizacji, bezpiecznego kodu, silnego uwierzytelniania, kopii zapasowych i monitoringu. W branży płatności jest zresztą formalnie wymagany — standard PCI DSS 4.0/4.0.1 (wymóg 6.4.2, obowiązkowy od 31 marca 2025 r.) wymaga dla publicznie dostępnych aplikacji webowych automatycznego rozwiązania wykrywającego i blokującego ataki, a WAF jest najczęstszym sposobem spełnienia tego wymogu.

Czy potrzebujesz WAF

• Mała strona firmowa lub blog na WordPressie: tak, w najprostszej formie — darmowy lub tani plan WAF w chmurze albo wtyczka bezpieczeństwa, plus automatyczne aktualizacje.
• Sklep internetowy: zdecydowanie tak, z limitami żądań na logowanie i koszyk oraz ochroną przed botami.
• Aplikacja SaaS i publiczne API: tak, najlepiej z regułami pozytywnymi dla API i integracją z monitoringiem (SIEM).
• Wewnętrzne aplikacje dostępne tylko przez VPN: WAF jest mniej pilny, ale wciąż przydatny jako ochrona przed atakami z przejętych komputerów wewnątrz sieci.