Bezpieczeństwo strony firmowej MŚP — minimum konfiguracji w 2026

Większość stron firmowych MŚP w Polsce ma dziś trzy rzeczy z porządnego stosu bezpieczeństwa: certyfikat HTTPS (bo bez tego przeglądarka straszy „niezabezpieczona”), jakąś formę panelu administracyjnego (WordPress, sklep, CMS) i prawie żadnej konfiguracji ponad to. Reszta — nagłówki bezpieczeństwa, ochrona przed botami, backupy, plan na incydent — najczęściej nie istnieje, albo została wyklikana raz i nikt nie wie, czy jeszcze działa.

Najczęściej słyszymy od nowych klientów, że „nasz hosting tym się zajmuje”. Czasem faktycznie się zajmuje, częściej — w zakresie, który kończy się dokładnie na pierwszym ataku. W tym artykule pokazujemy minimum konfiguracji bezpieczeństwa, które powinna mieć dziś każda strona firmowa MŚP w 2026: 4 warstwy, w 90% darmowe, do wdrożenia w 1–2 dni roboczych przez kogoś, kto rozumie DNS i panel hostingu. Bez korporacyjnych certyfikacji, bez audytu za 15 tysięcy, bez WAF-a za 800 USD/mies.

Co naprawdę grozi stronie firmowej MŚP w 2026

Zanim wejdziemy w konfigurację, jedna rzecz, która porządkuje resztę: strona firmowa MŚP nie jest atakowana, bo „ktoś was szuka”. Jest atakowana, bo automaty skanują cały internet, znajdują podatności i włamują się tam, gdzie taniej — czyli wszędzie, gdzie konfiguracja jest słabsza od średniej.

OWASP — globalna organizacja, która od 20 lat tworzy listę najczęstszych ryzyk dla aplikacji webowych — w wydaniu OWASP Top 10:2025 wprost przesuwa do góry dwie kategorie szczególnie istotne dla małych firm:

A02:2025 — Security Misconfiguration. Nieprawidłowa konfiguracja elementów bezpieczeństwa to dziś jedna z trzech czołowych przyczyn naruszeń. A03:2025 — Software Supply Chain Failures. Łańcuch dostaw oprogramowania: nieaktualne wtyczki WordPress, biblioteki npm/composer, motywy z marketplace. — OWASP Top 10:2025

Po polsku, językiem właściciela firmy: większość włamań na strony MŚP nie wynika z genialnego ataku „prawdziwego hakera”. Wynika z tego, że ktoś nie zaktualizował wtyczki, nie ustawił podstawowych nagłówków HTTP albo trzyma kod i bazę w jednym miejscu bez kopii zapasowej.

To zła wiadomość, bo skala problemu jest realna. Ale jest też dobra: skoro problem jest po stronie konfiguracji, to rozwiązanie też jest po stronie konfiguracji — nie wymaga zatrudnienia działu bezpieczeństwa. Cztery warstwy poniżej pokrywają zdecydowaną większość ryzyk z OWASP Top 10:2025 dla typowej strony firmowej MŚP.

Minimum 1: HTTPS i HSTS — fundament, którego nie można pominąć

HTTPS na stronie firmowej w 2026 r. nie jest już opcją — przeglądarki od kilku lat oznaczają strony bez certyfikatu jako „niezabezpieczone” i blokują dostęp do API geolokalizacji, kamery, mikrofonu. Jeśli Twoja strona w 2026 nadal otwiera się pod http://, masz nie tylko problem bezpieczeństwa, ale też SEO i konwersji.

1. HTTPS na poziomie hostingu — w 95% przypadków za darmo

Jeśli korzystasz z Cloudflare jako proxy DNS (oranżowa chmurka przy rekordzie), certyfikat dostajesz w cenie planu Free. Cloudflare opisuje to dosłownie:

Cloudflare wystawia — i odnawia — bezpłatne, niewspółdzielone, publicznie zaufane certyfikaty SSL dla wszystkich domen dodanych i aktywowanych w Cloudflare. — Cloudflare, dokumentacja Universal SSL

Universal SSL działa na każdym planie, w tym Free, i odnawia się sam. Alternatywą u dostawców hostingu współdzielonego jest Let’s Encrypt (też darmowy, też auto-odnawialny) — większość polskich hostingów (home.pl, nazwa.pl, OVH, Mikr.us) ma jednoklikową integrację.

Rozwiązanie: wejdź w panel hostingu → szukaj „SSL” lub „Let’s Encrypt” → włącz dla domeny głównej i wszystkich subdomen, których używasz. Jeśli korzystasz z Cloudflare — sprawdź w zakładce SSL/TLS, że tryb jest ustawiony na Full (strict), nie „Flexible” (Flexible szyfruje tylko między użytkownikiem a CF, między CF a Twoim hostingiem leci nieszyfrowany ruch — to gorzej niż brak HTTPS, bo daje fałszywe poczucie bezpieczeństwa).

2. HSTS — wymuś HTTPS na zawsze, na wszystkich subdomenach

Sam certyfikat to za mało. Bez nagłówka HSTS (HTTP Strict Transport Security) przeglądarka nadal może na chwilę wejść po http://, jeśli użytkownik wpisze adres bez https:// albo trafi z linku w starym e-mailu. To okno ataku „man-in-the-middle” w nieznanym Wi-Fi w kawiarni.

HSTS to jeden nagłówek odpowiedzi serwera, który mówi przeglądarce: „od teraz dla tej domeny już zawsze pytaj po HTTPS, niezależnie od tego, co wpisał użytkownik”. MDN opisuje to wprost: HSTS automatycznie upgraduje HTTP do HTTPS i nie pozwala użytkownikowi pominąć błędów certyfikatu, co chroni przed atakami pośrednika.

Konkretna wartość rekomendowana przez hstspreload.org (lista preloadowana przez Chrome, Firefox, Edge, Safari):

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

Co znaczą poszczególne kawałki:

• max-age=63072000 — przeglądarka pamięta, że ta domena ma być po HTTPS przez 2 lata od ostatniej wizyty. Minimum dla preload to 1 rok (31536000); 2 lata to wartość zalecana.
• includeSubDomains — reguła obejmuje też wszystkie subdomeny: sklep.firma.pl, api.firma.pl, mail.firma.pl. Każda z nich musi mieć HTTPS.
• preload — domena trafia do listy hardcodowanej w przeglądarkach. Każdy nowy użytkownik, zanim w ogóle wejdzie pierwszy raz, już wie, że tę domenę ma otwierać tylko po HTTPS.

W Cloudflare aktywujesz HSTS przez SSL/TLS → Edge Certificates → Always Use HTTPS (włącz) i HTTP Strict Transport Security (HSTS) → Enable, wybierz max-age 1–2 lata, zaznacz includeSubDomains i preload.

3. Pułapka HSTS — to jest niemal nieodwracalne

Tu bezwzględnie ostrzegamy. HSTS jest zapisywany w przeglądarce użytkownika na ustawiony max-age. Jeśli włączysz includeSubDomains i preload, a potem okaże się, że jakaś subdomena (np. wewnętrzny panel) nie ma certyfikatu, przeglądarki przestaną się tam łączyć — globalnie, dla wszystkich użytkowników.

Ostrzeżenie: nie włączaj HSTS z preload na domenie, na której nie masz pełnej kontroli nad wszystkimi subdomenami. Wycofanie wpisu z list preloadowanych Chrome/Firefox trwa kilka miesięcy i wymaga osobnego procesu zgłoszenia. Najpierw upewnij się, że WSZYSTKIE subdomeny działają po HTTPS, dopiero potem dodawaj preload.

Bezpieczna ścieżka wdrożenia: zacznij od max-age=300 (5 minut) bez preload, sprawdź przez tydzień, czy nic się nie zepsuło, zwiększaj stopniowo do 1 roku, dopiero potem dodawaj preload.

Minimum 2: nagłówki bezpieczeństwa — kilka linii, które blokują typowe ataki

Poza HSTS jest pakiet kilku nagłówków HTTP, które przeglądarki używają do egzekwowania reguł — kto może załadować Twoją stronę w iframe, skąd mogą się ładować skrypty, czy serwer ma „zgadywać” typ pliku. Ich brak to klasyczna A02:2025 Security Misconfiguration z OWASP Top 10:2025 — łatwy cel skanerów automatycznych.

Web.dev (zespół Google odpowiedzialny za standardy webowe) podaje listę krytycznych nagłówków: Content Security Policy, X-Content-Type-Options, X-Frame-Options, HSTS oraz mniej oczywiste CORP/COOP/COEP dla aplikacji wymagających izolacji. Dla typowej strony firmowej MŚP minimum to cztery z nich.

1. Content Security Policy (CSP) — biała lista skryptów

CSP mówi przeglądarce: „skrypty wolno ładować tylko z tych domen, obrazy z tych, fonty z tych”. Jeśli atakujący wstrzyknie kod z innej domeny (klasyczny XSS — cross-site scripting), przeglądarka go zablokuje.

Dla statycznej strony firmowej (Astro, Hugo, Next static export) prosty CSP wygląda tak:

Content-Security-Policy: default-src 'self'; script-src 'self' https://www.googletagmanager.com; img-src 'self' data: https:; style-src 'self' 'unsafe-inline'; font-src 'self' https://fonts.gstatic.com; frame-ancestors 'none';

Co warto rozumieć:

• default-src 'self' — wszystko domyślnie tylko z naszej domeny.
• script-src — JS tylko z własnej domeny + ewentualnie GTM (jeśli używasz Google Tag Manager).
• frame-ancestors 'none' — nikt nie może osadzić Twojej strony w iframe (zabezpieczenie przed clickjackingiem; nowoczesna alternatywa dla X-Frame-Options).

CSP to nagłówek, który najłatwiej źle ustawić. Dlatego web.dev rekomenduje najpierw tryb „Report-Only”: nagłówek nazywa się wtedy Content-Security-Policy-Report-Only, przeglądarka tylko raportuje naruszenia (do report-uri albo do konsoli DevTools), nic nie blokuje. Po 1–2 tygodniach zbierania logów widać, czego naprawdę używasz, i można przejść na egzekwujący Content-Security-Policy.

2. X-Content-Type-Options i X-Frame-Options — dwa one-linery

Te dwa nagłówki to klasyk, który powinien być w każdej konfiguracji od dnia zero:

X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Referrer-Policy: strict-origin-when-cross-origin

• X-Content-Type-Options: nosniff — przeglądarka ma traktować pliki dokładnie tak, jak deklaruje serwer (nagłówek Content-Type). Bez tego niektóre przeglądarki „zgadują” typ na podstawie zawartości — i można im podsunąć obrazek, który okazuje się skryptem.
• X-Frame-Options: SAMEORIGIN — Twoją stronę można osadzić w iframe tylko z własnej domeny. Chroni przed clickjackingiem, w którym atakujący osadza Twój panel logowania w przezroczystym iframe na fałszywej stronie. Wartość DENY jest ostrzejsza (żaden iframe), ale czasem łamie integracje (np. podgląd Open Graph na LinkedIn).
• Referrer-Policy: strict-origin-when-cross-origin — gdy użytkownik klika link z Twojej strony, do strony docelowej leci tylko sama domena źródła (bez pełnej ścieżki z parametrami). To ochrona prywatności użytkowników i zabezpieczenie przed wyciekaniem tokenów w URL.

3. Gdzie to wpisać

Miejsce zależy od stosu:

W każdym z powyższych miejsc weryfikujesz wynik na securityheaders.com (darmowy skaner Scotta Helme’a) — wpisujesz domenę, dostajesz ocenę A–F i listę brakujących nagłówków. Z naszej praktyki: większość niesprawdzonych stron firmowych w Polsce dostaje dziś F lub D, podczas gdy minimum, na które stać każdą stronę firmową, to A.

Minimum 3: WAF, rate limiting i ochrona przed botami

Trzecia warstwa to Web Application Firewall (WAF) — serwis, który filtruje ruch przychodzący jeszcze zanim dotrze do Twojego hostingu. Cloudflare WAF jest dostępny od planu Free i robi rzecz, której Twój hosting prawdopodobnie nie robi:

WAF Cloudflare sprawdza przychodzące żądania webowe i API i filtruje niepożądany ruch na podstawie zestawów reguł zwanych rulesets. — Cloudflare, dokumentacja WAF

Po polsku: WAF czyta każdy request (URL, nagłówki, body) i odrzuca te, które wyglądają na atak — próby SQL injection, XSS, próby skanowania znanych ścieżek panela admina, próby brute force logowania.

1. Co dostajesz na Free

Plan Free Cloudflare daje:

• Custom rules — własne reguły WAF (np. „blokuj wszystkie żądania POST do /wp-login.php z krajów spoza Polski”).
• 1 Rate limiting rule — np. „nie więcej niż 10 prób logowania na minutę z jednego IP”.
• Bot Fight Mode — automatyczna blokada znanych botów skanujących.
• Managed Rules (ograniczone) — z dokumentacji Cloudflare: „pre-konfigurowane zarządzane rulesety dające natychmiastową ochronę” z aktualizacjami i ochroną przed zero-day.

Pełne Managed Rules chroniące przed atakami z OWASP Top 10 (SQL injection, XSS, command injection) to plan Pro (20 USD/mies. za domenę). Dla typowej strony firmowej MŚP rekomendacja jest prosta: zacznij od Free + włącz Bot Fight Mode + ustaw 1 rate limit na formularzach kontaktu / logowania, dopiero gdy widzisz realne ataki — przejdź na Pro.

2. Rate limiting kontra WAF — to dwie różne rzeczy

Często mylone — warto rozumieć różnicę:

• WAF filtruje co może przejść (zawartość żądania).
• Rate limiting filtruje ile może przejść (liczba żądań w czasie).

WAF zatrzyma jednorazowy złośliwy request. Rate limiting zatrzyma 1000 prób zgadnięcia hasła w ciągu minuty (nawet jeśli każdy pojedynczy request wygląda niewinnie). Potrzebujesz obu — to narzędzia komplementarne, nie zamienne.

3. Co najczęściej blokujemy u klientów

Z naszej praktyki — typowy pakiet reguł WAF + rate limiting dla strony firmowej MŚP w Polsce wygląda tak:

• Blokada żądań do typowych ścieżek WordPress (/wp-admin, /wp-login.php, /xmlrpc.php) z krajów spoza Polski/UE — jeśli używasz WP, ale jesteś jedynym adminem i logujesz się z Polski.
• Rate limit na formularzu kontaktowym — typowo 3 wysyłki na minutę z jednego IP (chroni przed spamem).
• Rate limit na endpointach API — jeśli masz publiczne API.
• Blokada User-Agent znanych skanerów (np. sqlmap, nikto, nmap) — listy są publicznie dostępne.

To są reguły, które widać w logach po godzinie od włączenia — kilkaset zablokowanych żądań na typową, niewielką stronę firmową dziennie. Nie dlatego, że jesteś celem — dlatego, że internet jest dziś tak głośny.

Minimum 4: backupy, monitoring i plan na incydent

Trzy poprzednie warstwy zmniejszają prawdopodobieństwo udanego ataku. Czwarta przygotowuje na wypadek, gdy mimo wszystko coś się wydarzy. Bo jeśli atak się uda, pytanie nie brzmi „czy mamy backup?”, tylko „jak stary jest ten backup i czy w ogóle działa?“.

1. Backup kodu (Git) ≠ backup danych

Najczęstszy błąd: właściciel strony firmowej myśli, że ma backup, bo „strona jest w GitHubie”. Ale GitHub trzyma tylko kod — nie trzyma:

• bazy danych (treści CMS, użytkowników, zamówień),
• przesłanych plików (zdjęcia, PDF-y, załączniki),
• konfiguracji serwera,
• certyfikatów SSL z prywatnymi kluczami,
• logów dostępu (potrzebnych po incydencie do analizy, co się stało).

Realny backup składa się z trzech kawałków:

• Kod — repozytorium Git (GitHub / GitLab / własny).
• Dane — eksport bazy danych + przesłane pliki, najlepiej raz dziennie, do innej lokalizacji niż produkcja (S3-compatible storage, Backblaze B2, Cloudflare R2 — wszystkie poniżej 50 zł/mies. dla typowej strony MŚP).
• Konfiguracja — eksport ustawień DNS, SSL, WAF, mailingu (zapisany w pliku tekstowym w repo lub menedżerze haseł).

Strony statyczne (Astro, Hugo) mają tę zaletę, że punkty 2 i 3 są minimalne — pisaliśmy o tym szerzej w Astro vs WordPress dla strony firmowej. Strony oparte o WordPress wymagają osobnej wtyczki backupowej (UpdraftPlus, BackWPup) skonfigurowanej tak, żeby wysyłała backup poza serwer hostingu (na zewnętrzne S3 / Google Drive).

2. Monitoring — wiedz pierwszy, że strona padła

Drugi element to monitoring uptime. Bez niego dowiesz się, że strona nie działa, kiedy zadzwoni klient. Z nim — w 5 minut po incydencie dostajesz e-mail / SMS.

Darmowe i sensowne opcje dla MŚP:

• UptimeRobot — sprawdza co 5 min, do 50 monitorów na planie Free.
• BetterStack (Better Uptime) — co 30 sekund, ładniejszy panel, status page wliczona.
• Cloudflare Health Checks — wbudowane w plan Free CF, wymaga konfiguracji w panelu.

Monitorujemy minimum: stronę główną (czy zwraca 200), endpoint kontaktowy (czy formularz działa), certyfikat SSL (kiedy wygasa) i rekord DNS A/AAAA (czy ktoś nie zmienił bez naszej wiedzy).

3. Plan na incydent — kogo wołać, co odłączyć

To najczęściej pomijany element, bo wymaga tylko kartki, nie konfiguracji. A właśnie dlatego nie istnieje. Minimum to dokument na 1 stronę A4 z odpowiedziami:

• Kto jest właścicielem domeny (kto może ją zablokować / przekierować) — kontakt 24/7.
• Kto jest właścicielem hostingu — kontakt 24/7.
• Jak wyłączyć stronę z internetu w 5 minut (np. Cloudflare → Pause Cloudflare on Site / wyłączenie rekordu DNS A).
• Skąd wziąć ostatni backup (URL, dane logowania).
• Numer do firmy IT, która może pomóc w nocy (jeśli macie taką umowę).
• E-mail UODO i RODO checklist (jeśli wyciekły dane osobowe — masz 72 godziny na zgłoszenie).

Ten dokument trzymaj poza stroną firmową (np. w menedżerze haseł zespołu, w wydrukowanej kopii w sejfie). Bo jeśli włamanie obejmie też panel administracyjny, dostęp do dokumentu w panelu masz zerowy.

Podsumowanie

Powyższe 4 warstwy to minimum, nie maksimum. Świadomie pomijamy elementy, które dla typowej strony firmowej MŚP są nieproporcjonalne do ryzyka: pełny pentest (sensowny dla sklepów e-commerce z transakcjami i firm B2B z panelem klienta), WAF klasy enterprise (Cloudflare Enterprise, Akamai, Imperva — uzasadnione przy realnym ruchu i transakcjach), bug bounty program (sensowny przy publicznym API), SIEM (przy małej skali to overkill). Dla typowej strony wizytówkowej z formularzem kontaktu — to przerost.

Bezpieczeństwo strony firmowej MŚP w 2026 r. nie jest projektem za 50 tys. zł. To 4 warstwy, które razem kosztują tyle, co dwa lunche w mieście:

• HTTPS + HSTS — Universal SSL Cloudflare lub Let’s Encrypt, plus jeden nagłówek HSTS z ostrożnym max-age (zaczynaj od 5 minut, nie od razu 2 lata z preload).
• Nagłówki bezpieczeństwa — Content-Security-Policy (najpierw Report-Only), X-Content-Type-Options: nosniff, X-Frame-Options: SAMEORIGIN, Referrer-Policy: strict-origin-when-cross-origin. Sprawdzasz wynik na securityheaders.com — celem jest A.
• WAF + rate limiting — Cloudflare Free + Bot Fight Mode + 1 rate limit na formularzu kontaktu. Pro (20 USD/mies.) tylko jeśli widzisz realny ruch ataków w logach.
• Backupy + monitoring + plan na incydent — backup poza hosting, UptimeRobot lub BetterStack, dokument 1 strona A4 z planem awaryjnym poza stroną.

Razem: 1–2 dni pracy osoby, która rozumie DNS i panel hostingu, koszt rzędu 0–50 zł/mies. To naprawdę jest minimum, nie maksimum — i właśnie dlatego brak tego minimum jest dziś najpoważniejszym ryzykiem dla typowej strony firmowej MŚP w Polsce.

Wskazówka: zanim zlecisz audyt zewnętrzny, wpisz swoją domenę na securityheaders.com i sprawdź ocenę. Jeśli widzisz F lub D — zacznij od nagłówków, to jednodniowa robota dająca największy zwrot z włożonego czasu. Jeśli A lub B — masz solidny fundament i warto sprawdzić pozostałe trzy warstwy. Standardowo robimy ten audyt razem z włączeniem nowej strony do naszego stacku analitycznego — jeśli interesuje Cię, jak to wygląda technicznie, chętnie podpowiemy.