Bezpieczeństwo to nie opcja — to fundament

Każdego dnia tysiące stron internetowych pada ofiarą ataków hakerskich. Nie chodzi tylko o duże korporacje — małe i średnie firmy są często łatwiejszym celem, bo zwykle mają słabsze zabezpieczenia. Atakujący nie wybierają celów ręcznie; używają automatycznych narzędzi, które skanują miliony stron w poszukiwaniu znanych luk.

W tym artykule omawiamy najważniejsze zasady bezpieczeństwa, które stosujemy przy budowie i utrzymaniu stron internetowych. Nie jest to kompletny podręcznik bezpieczeństwa IT, ale solidny fundament, który chroni przed zdecydowaną większością zagrożeń.

HTTPS — absolutne minimum

W 2026 roku strona bez certyfikatu SSL to anachronizm. HTTPS szyfruje komunikację między przeglądarką użytkownika a serwerem, chroniąc przed:

  • Podsłuchiwaniem — nikt po drodze (ISP, sieci Wi-Fi) nie może odczytać przesyłanych danych
  • Modyfikacją — atakujący nie może zmienić treści strony w locie (np. wstrzyknąć reklam lub złośliwego kodu)
  • Podszywaniem się — certyfikat SSL potwierdza tożsamość serwera

Certyfikaty Let's Encrypt są darmowe i automatycznie odnawialne. Nie ma żadnego usprawiedliwienia dla braku HTTPS.

Ważne: samo posiadanie certyfikatu to za mało. Należy również:

  • Przekierować cały ruch HTTP na HTTPS (301 redirect)
  • Wymusić HTTPS nagłówkiem HSTS
  • Używać protokołu TLS 1.2 lub 1.3 (starsze wersje mają znane luki)

Nagłówki bezpieczeństwa HTTP

Poprawnie skonfigurowane nagłówki HTTP to jedna z najskuteczniejszych i najtańszych metod ochrony strony. Oto najważniejsze z nich:

Strict-Transport-Security (HSTS)

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Informuje przeglądarkę, że strona powinna być dostępna wyłącznie przez HTTPS. Po pierwszej wizycie przeglądarka automatycznie przekieruje wszystkie żądania na HTTPS, nawet jeśli użytkownik wpisze http://.

X-Content-Type-Options

X-Content-Type-Options: nosniff

Zapobiega interpretowaniu plików niezgodnie z ich deklarowanym typem MIME. Blokuje ataki polegające na ukryciu złośliwego kodu w pliku udającym obraz lub inny bezpieczny zasób.

X-Frame-Options

X-Frame-Options: SAMEORIGIN

Zapobiega osadzaniu strony w ramce (iframe) na obcych stronach. Chroni przed atakami clickjacking, w których atakujący nakłada niewidoczną ramkę z Twoją stroną na swoją stronę, przechwytując kliknięcia użytkownika.

Content-Security-Policy (CSP)

Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'

CSP to najpotężniejszy nagłówek bezpieczeństwa. Definiuje, z jakich źródeł przeglądarka może ładować skrypty, style, obrazy i inne zasoby. Skutecznie blokuje ataki XSS (Cross-Site Scripting), ponieważ przeglądarka odmówi wykonania skryptu, który nie pochodzi z dozwolonego źródła.

Referrer-Policy

Referrer-Policy: strict-origin-when-cross-origin

Kontroluje, ile informacji o adresie URL jest przesyłane przy nawigacji na inne strony. Chroni prywatność użytkowników i zapobiega wyciekowi wrażliwych danych w adresach URL.

OWASP Top 10 — najczęstsze zagrożenia

OWASP (Open Web Application Security Project) publikuje listę dziesięciu najpoważniejszych zagrożeń dla aplikacji webowych. Oto najistotniejsze z nich w kontekście stron firmowych:

Injection (wstrzyknięcia)

SQL injection, command injection, template injection — ataki polegające na wstrzyknięciu złośliwego kodu przez dane wejściowe. Obrona:

  • Parametryzowane zapytania — nigdy nie buduj zapytań SQL przez konkatenację stringów
  • Walidacja danych wejściowych — sprawdzaj typ, długość i format każdego parametru
  • Escape'owanie output — HTML entities, SQL escaping

W Go standardowa biblioteka database/sql wymusza parametryzowane zapytania, co eliminuje ryzyko SQL injection. Pakiet html/template automatycznie escape'uje HTML, chroniąc przed XSS.

Broken Authentication

Ataki na mechanizmy uwierzytelniania: brute-force logowania, kradzież sesji, słabe hasła. Obrona:

  • Rate limiting — ograniczenie liczby prób logowania
  • Silne hasła — wymuszaj minimalną długość i złożoność
  • Secure cookies — flagi Secure, HttpOnly, SameSite
  • Dwuskładnikowe uwierzytelnianie (2FA) — dodatkowa warstwa zabezpieczenia

Security Misconfiguration

Błędna konfiguracja serwera to jedno z najczęstszych źródeł luk:

  • Domyślne hasła i konta
  • Wylistowane katalogi (directory listing)
  • Verbose error messages w produkcji
  • Niepotrzebne otwarte porty
  • Brak aktualizacji oprogramowania

Rate Limiting — ochrona przed nadużyciami

Rate limiting to mechanizm ograniczający liczbę żądań, które klient może wysłać w określonym czasie. W naszej konfiguracji Nginx ustawiamy limit na 10 żądań na sekundę per adres IP.

Chroni to przed:

  • Atakami brute-force — automatyczne próby odgadnięcia hasła
  • DDoS — próby przeciążenia serwera
  • Web scraping — masowe pobieranie treści
  • Nadużyciami API — np. spamowanie formularza kontaktowego

Konfiguracja w Nginx jest prosta:

limit_req_zone $binary_remote_addr zone=general:10m rate=10r/s;

server {
    location / {
        limit_req zone=general burst=20 nodelay;
    }
}

Parametr burst=20 pozwala na krótkotrwałe przekroczenie limitu (np. przy szybkim ładowaniu strony z wieloma zasobami), ale ogólne tempo jest ograniczone.

Walidacja danych — nigdy nie ufaj klientowi

Fundamentalna zasada bezpieczeństwa webowego: nigdy nie ufaj danym przychodzącym od klienta. Dotyczy to:

  • Formularzy HTML
  • Parametrów URL
  • Ciasteczek
  • Nagłówków HTTP
  • Ciała żądania (request body)

Każda dana wejściowa musi być walidowana po stronie serwera, niezależnie od walidacji po stronie klienta. Walidacja JavaScript w przeglądarce to wygoda dla użytkownika, nie mechanizm bezpieczeństwa — można ją łatwo obejść.

W naszych formularzach kontaktowych stosujemy:

  • Limit rozmiaru — io.LimitReader ogranicza rozmiar ciała żądania do 10 KB
  • Walidację typów — dekodowanie JSON z typowaną strukturą
  • Sanityzację — strings.TrimSpace i html.EscapeString na wszystkich danych wejściowych
  • Walidację logiczną — sprawdzenie formatu email, wymaganych pól

Minimalizm jako strategia bezpieczeństwa

Jedną z naszych kluczowych strategii bezpieczeństwa jest minimalizm:

  • Brak frameworków — mniej kodu zewnętrznego = mniejsza powierzchnia ataku
  • Brak bazy danych (gdzie to możliwe) — eliminacja całej klasy ataków SQL injection
  • Minimalne zależności — mniej bibliotek do aktualizowania i audytowania
  • Minimalne uprawnienia — kontenery Docker działają z ograniczonymi uprawnieniami
  • Minimalna ekspozycja — tylko niezbędne porty są otwarte

Nasze strony firmowe budowane w Go nie mają bazy danych, nie mają panelu administracyjnego i mają minimalne zależności. To drastycznie ogranicza wektory ataku.

Aktualizacje i monitoring

Bezpieczeństwo to proces, nie jednorazowe działanie:

  • Regularne aktualizacje — system operacyjny, Docker, obrazy bazowe, zależności Go
  • Monitoring logów — automatyczne wykrywanie podejrzanej aktywności
  • Skanowanie podatności — okresowe sprawdzanie znanych luk w zależnościach
  • Backup — regularne kopie zapasowe z testami odtwarzania

Polecenie go mod tidy i docker pull powinny być częścią regularnej procedury utrzymaniowej.

Checklist bezpieczeństwa dla stron firmowych

Na zakończenie — lista kontrolna, którą stosujemy przy każdym wdrożeniu:

  • [ ] HTTPS z certyfikatem SSL (Let's Encrypt)
  • [ ] Przekierowanie HTTP na HTTPS
  • [ ] Nagłówek HSTS
  • [ ] Nagłówek X-Content-Type-Options: nosniff
  • [ ] Nagłówek X-Frame-Options: SAMEORIGIN
  • [ ] Content-Security-Policy
  • [ ] Rate limiting (Nginx)
  • [ ] Walidacja danych wejściowych po stronie serwera
  • [ ] Escape'owanie danych wyjściowych (HTML, JSON)
  • [ ] Minimalne uprawnienia kontenerów Docker
  • [ ] Aktualne wersje oprogramowania
  • [ ] Regularne kopie zapasowe
  • [ ] Monitoring logów i alertowanie

Podsumowanie

Bezpieczeństwo stron internetowych to nie tajemna sztuka dostępna tylko dla specjalistów. To zestaw znanych, sprawdzonych praktyk, które trzeba konsekwentnie stosować. Większość ataków wykorzystuje znane luki i prostą niedbałość — odpowiednia konfiguracja eliminuje te zagrożenia.

Jeśli nie jesteś pewien, czy Twoja strona jest odpowiednio zabezpieczona, skontaktuj się z nami. Przeprowadzimy audyt bezpieczeństwa i wskażemy, co wymaga poprawy.