Bezpieczeństwo strony jest częścią web developmentu, a nie zadaniem na sam koniec. W 2026 roku jedna luka może ujawnić dane użytkowników, pogorszyć pozycje w Google i zaufanie klientów oraz narazić firmę na odpowiedzialność prawną, między innymi na gruncie RODO/GDPR.
Dlaczego bezpieczeństwo strony jest ważniejsze niż kiedykolwiek?
Boty automatycznie skanują internet w poszukiwaniu znanych luk. Źle skonfigurowany serwer lub podatna biblioteka mogą zostać wykorzystane w ciągu kilku minut od publikacji strony.
Konsekwencje naruszenia bezpieczeństwa:
- SEO – Google oznacza strony jako „This site may be hacked”, co powoduje spadki pozycji i CTR
- Zaufanie użytkowników – 85% użytkowników opuszcza stronę po ostrzeżeniu o zagrożeniu
- Odpowiedzialność prawna – RODO, CCPA i inne regulacje przewidują wysokie kary
- Ciągłość biznesu – DDoS, ransomware czy kradzież danych mogą zatrzymać firmę
Bezpieczeństwo i wydajność są powiązane — szybkie, dobrze zaprojektowane strony są trudniejsze do zaatakowania.
HTTPS – absolutna podstawa
HTTPS szyfruje połączenie między przeglądarką a serwerem z użyciem TLS (Transport Layer Security).
Bez HTTPS:
- przeglądarka pokazuje „Not Secure”
- Google obniża ranking
- dane są przesyłane w formie jawnej
Jak poprawnie wdrożyć HTTPS:
- użyj certyfikatu SSL (np. Let’s Encrypt)
- stosuj TLS 1.2+ (najlepiej 1.3)
- ustaw automatyczne odnawianie certyfikatu
- wdroż HSTS:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
- przekieruj HTTP → HTTPS (301)
- unikaj mixed content
Nagłówki bezpieczeństwa HTTP
Content Security Policy (CSP)
Content Security Policy (CSP) ogranicza źródła, z których przeglądarka może pobierać skrypty i inne zasoby:
Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-cdn.com;
X-Frame-Options
Nagłówek X-Frame-Options może ograniczyć osadzanie strony w ramce i pomóc chronić przed clickjackingiem:
X-Frame-Options: DENY
X-Content-Type-Options
X-Content-Type-Options: nosniff
Referrer-Policy
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy
Permissions-Policy: camera=(), microphone=(), geolocation=()
OWASP Top 10 – najważniejsze zagrożenia
| # | Zagrożenie | Opis |
|---|---|---|
| 1 | Broken Access Control | dostęp do nieautoryzowanych danych |
| 2 | Cryptographic Failures | słabe szyfrowanie |
| 3 | Injection (SQLi, XSS) | wstrzyknięcie kodu |
| 4 | Insecure Design | błędy architektury |
| 5 | Misconfiguration | błędna konfiguracja |
| 6 | Vulnerable Components | podatne biblioteki |
| 7 | Auth Failures | błędy logowania |
| 8 | Integrity Failures | niezweryfikowany kod |
| 9 | Logging Failures | brak monitoringu |
| 10 | SSRF | dostęp do zasobów wewnętrznych |
SQL Injection (SQLi)
SQL injection jest możliwy, gdy aplikacja wstawia dane użytkownika bezpośrednio do zapytania SQL.
SELECT * FROM users WHERE username = '$input';
Jak zapobiegać:
- prepared statements
- ORM
- walidacja danych
- zasada minimalnych uprawnień
Cross-Site Scripting (XSS)
Cross-site scripting (XSS) polega na wstrzyknięciu do strony skryptu, który może uruchomić się w przeglądarce użytkownika.
Typy:
- stored
- reflected
- DOM-based
Jak zapobiegać:
- escape output
- CSP
- HttpOnly cookies
Set-Cookie: sessionId=abc123; HttpOnly; Secure; SameSite=Strict
CSRF
Atak CSRF próbuje skłonić zalogowaną przeglądarkę do wykonania działania bez świadomej zgody użytkownika.
Ochrona:
- CSRF tokens
- SameSite cookies
- walidacja nagłówków
Autoryzacja i sesje
Hasła:
- bcrypt / Argon2
- polityka haseł
- blokada konta
MFA:
- TOTP (Google Authenticator)
- passkeys / WebAuthn
Sesje:
- bezpieczne ID
- wygaszanie
- regeneracja ID
Bezpieczeństwo zależności
Aplikacje korzystają z wielu bibliotek zewnętrznych. Każda wymaga aktualizacji i kontroli pod kątem znanych podatności.
Dobre praktyki:
npm audit/composer audit- Dependabot / Renovate
- unikaj porzuconych pakietów
SRI:
<script src="cdn.js" integrity="sha384-..." crossorigin="anonymous"></script>
Błędna konfiguracja
Błędna konfiguracja serwera lub aplikacji jest częstym źródłem luk.
Napraw:
- domyślne hasła
- directory listing
- debug w produkcji
- otwarte porty
- publiczne
.env - publiczne storage
Monitoring i reakcja
Bez monitoringu włamanie może pozostać niewykryte przez długi czas.
Co monitorować:
- logowania
- zmiany plików
- ruch wychodzący
- błędy
Narzędzia:
- Google Search Console
- Cloudflare
- Fail2ban
- OWASP ZAP
Plan reagowania
Plan reagowania powinien określać:
- kto reaguje
- jak ocenić wyciek
- zgłoszenie (72h – RODO)
- odzyskiwanie
Checklist bezpieczeństwa
HTTPS
- SSL + auto-renew
- TLS 1.2+
- HSTS
- redirect 301
Headers
- CSP
- X-Frame-Options
- X-Content-Type
- Referrer
- Permissions
Aplikacja
- walidacja inputu
- prepared statements
- CSRF
- HttpOnly cookies
Auth
- hash haseł
- MFA
- blokady
- sesje
Dependencies
- brak luk
- aktualizacje
- brak defaultów
Monitoring
- logi
- WAF
- GSC
- plan reakcji
Podsumowanie
Zabezpieczenia są częścią utrzymania strony: ograniczają ryzyko wycieku danych, przestojów i utraty zaufania.
Brak podstawowych zabezpieczeń może prowadzić do:
- spadki SEO
- utrata użytkowników
- ryzyko prawne
Przed publikacją sprawdź stronę w Mozilla Observatory i SecurityHeaders.com. Oba narzędzia są darmowe, podają ocenę wraz z konkretnymi zaleceniami i wykonują test w kilka sekund. Celuj w ocenę A+ w obu serwisach.