Praktyczne zabezpieczenia warstwy HTTP: nagłówki bezpieczeństwa, CSP, cookies, rate limiting oraz podstawowy monitoring na produkcji.
Bezpieczeństwo HTTP to najszybszy zysk na produkcji
Masz solidny backend, bezpieczny język programowania i poprawną logikę aplikacji. To ogromna przewaga. Problem w tym, że większość ataków nie zaczyna się w kodzie, tylko w przeglądarce i na warstwie HTTP.
Dobrze skonfigurowane nagłówki, cookies i podstawowy rate limiting potrafią zablokować całe klasy ataków bez pisania ani jednej linijki nowej logiki biznesowej.
Podstawowe nagłówki bezpieczeństwa HTTP (must-have na produkcji)
To absolutne minimum, które powinno znaleźć się na każdej stronie produkcyjnej – niezależnie od technologii.
Wymusza HTTPS i chroni przed atakami typu downgrade.
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
Blokuje sniffing MIME w przeglądarce.
X-Content-Type-Options: nosniff
Kontroluje, ile informacji o URL wysyłasz do zewnętrznych stron.
Referrer-Policy: strict-origin-when-cross-origin
Odcina dostęp do API przeglądarki, których nie używasz.
Permissions-Policy: camera=(), microphone=(), geolocation=()
Content Security Policy – krok po kroku
CSP to najpotężniejszy nagłówek bezpieczeństwa w przeglądarce. Dobrze ustawiony praktycznie eliminuje XSS.
Dla stron bez ciężkiego JavaScriptu możesz zacząć bardzo restrykcyjnie:
Content-Security-Policy:
default-src 'self';
img-src 'self' https:;
style-src 'self';
script-src 'self';
object-src 'none';
base-uri 'self';
frame-ancestors 'none';
Kluczowa zasada: nie pozwalaj domyślnie na nic, a następnie dodawaj wyjątki tylko tam, gdzie faktycznie są potrzebne.
Cookies: Secure, HttpOnly, SameSite
Źle ustawione cookies to najkrótsza droga do przejęcia sesji użytkownika.
- Secure – cookie wysyłane tylko przez HTTPS.
- HttpOnly – niedostępne dla JavaScriptu.
- SameSite=Lax – domyślny wybór dla większości aplikacji.
SameSite=None stosuj wyłącznie wtedy, gdy naprawdę musisz (np. zewnętrzne integracje) i zawsze w parze z Secure.
Rate limiting – ochrona formularzy i logowania
Ataki brute-force i spam formularzy nie wymagają żadnych luk w kodzie.
Minimalna, rozsądna konfiguracja:
- formularz kontaktowy: 5–10 requestów / minutę / IP
- logowanie: 3–5 prób / minutę
- rejestracja: niski limit + captcha
Monitoring i alerty – minimum dla małej firmy
Nie musisz mieć SOC ani zespołu DevSecOps. Wystarczy:
Minimum operacyjne
- alerty 5xx oraz nietypowe wzrosty odpowiedzi 4xx
- logowanie zdarzeń prób logowania i aktywacji rate limitu
- monitoring dostępności strony (uptime / healthcheck)
To pozwala reagować zanim problem stanie się incydentem.