Część 5 serii „Bezpieczeństwo stron w UE: 10 kroków do lepszej oceny"
Dlaczego security.txt
Badacz bezpieczeństwa znajduje podatność na Twojej stronie. Z kim się kontaktuje?
Bez security.txt: Przeszukuje witrynę, znajduje info@, wysyła e-mail. Trafia do działu marketingu, zostaje usunięty jako spam lub zignorowany. Podatność pozostaje otwarta.
Z security.txt: Odwiedza /.well-known/security.txt, znajduje kontakt bezpieczeństwa, klucz PGP i politykę ujawniania. Zgłoszenie natychmiast trafia do właściwego zespołu.
Wskaźnik wdrożenia w UE: 2,8%. A jednak: witryny z security.txt uzyskują średnio 31% wyższy wynik niż te bez niego.
Korelacja
| Metryka | Z security.txt | BEZ | Współczynnik |
|---|---|---|---|
| Wynik kompozytowy | 55 | 42 | +31% |
| HSTS | 72% | 26% | 2,8x |
| CSP | 47% | 10% | 4,7x |
| Ocena F | 6% | 44% | 7x mniej |
security.txt nie jest panaceum. Ale ci, którzy poświęcają czas na jego konfigurację, zazwyczaj zadbali też o wszystko inne.
Jak skonfigurować security.txt
Krok 1: Utwórz plik
Utwórz plik /.well-known/security.txt na swoim serwerze:
Contact: mailto:security@twoja-domena.pl
Expires: 2027-04-13T00:00:00.000Z
Preferred-Languages: pl
Wymagane pola (RFC 9116):
- Contact: — adres e-mail lub URL do zgłoszeń bezpieczeństwa
- Expires: — data wygaśnięcia (maksymalnie 1 rok w przyszłości)
Opcjonalne pola:
- Encryption: — klucz PGP do szyfrowanych zgłoszeń
- Acknowledgments: — podziękowania dla odpowiedzialnych zgłaszających
- Canonical: — kanoniczny URL pliku
- Policy: — link do Polityki Ujawniania Podatności
- Hiring: — link do ofert pracy w zespole bezpieczeństwa
Krok 2: Udostępnij plik
Plik musi być dostępny pod https://twoja-domena.pl/.well-known/security.txt. Dla większości konfiguracji:
Nginx:
location = /.well-known/security.txt {
alias /var/www/twoja-domena.pl/security.txt;
}
Apache: Po prostu umieść plik w /.well-known/ w katalogu głównym.
WordPress: Użyj wtyczki „WP Security.txt" lub ręcznie umieść plik w .well-known/ w katalogu głównym.
Krok 3: Dodaj klucz PGP (zalecane)
Contact: mailto:security@twoja-domena.pl
Encryption: https://twoja-domena.pl/.well-known/pgp-key.txt
Expires: 2027-04-13T00:00:00.000Z
ENISA zaleca opcję szyfrowania, aby badacze bezpieczeństwa mogli przesyłać wrażliwe informacje w chronionym formacie.
Wdrożenie w branżach
| Branża | Wdrożenie | Śr. wynik z | Śr. wynik bez |
|---|---|---|---|
| Bankowość | 23,9% | 69 | 55 |
| E-Commerce | 15,6% | 64 | 53 |
| Edukacja | 8,1% | 53 | 42 |
| Technologia | 5,3% | 63 | 45 |
| Ochrona zdrowia | 2,0% | 58 | 42 |
| Hotelarstwo | 1,1% | 51 | 40 |
Bankowość prowadzi — prawie co czwarty bank posiada security.txt. Hotelarstwo (hotele, restauracje) ma 1,1%.
Kontekst regulacyjny
- NIS2 art. 21 ust. 2 lit. e) wyraźnie wymaga „obsługi i ujawniania podatności" — security.txt jest ustandaryzowanym mechanizmem w tym zakresie
- CRA art. 14 — skoordynowane ujawnianie podatności staje się obowiązkowe od grudnia 2027 r. dla producentów produktów cyfrowych
- ENISA wymienia security.txt jako dobrą praktykę w zakresie ujawniania podatności
- Krajowe CERT w Europie (NASK/CERT.PL, NCSC-NL, ANSSI, BSI) zalecają lub stosują security.txt na własnych domenach
Typowe błędy
1. Zapomnienie o Expires. Bez Expires plik jest nieprawidłowy zgodnie z RFC 9116. Ustaw datę na 1 rok w przyszłości i przypomnij sobie o aktualizacji.
2. HTTP zamiast HTTPS. Plik musi być serwowany przez HTTPS — nieszyfrowany security.txt może zostać zmodyfikowany w drodze.
3. info@ jako kontakt. Contact: mailto:info@... trafia do marketingu. Skonfiguruj dedykowany adres security@, który dociera do osoby odpowiedzialnej za bezpieczeństwo.
Sprawdź swój security.txt
W następnym tygodniu w części 6: DKIM — dlaczego tylko 31% domen w UE podpisuje swoje e-maile.