Ostatnio klient pokazał mi raport z seohost.pl, gdzie sprawdzają czy strony jego klientów mają plik security.txt. Pomyślałem - "fajnie, dodam to u siebie". 5 linijek tekstu, plik na serwerze, gotowe.

Potem z czystej ciekawości sprawdziłem czy seohost sam go ma. Nie ma. Jak szewc bez butów.

To mnie zainteresowało, więc poszedłem dalej. Sprawdziłem 12 największych polskich hostingów. Wyniki są dziwniejsze niż się spodziewałem.

Co to w ogóle jest ten security.txt?

Krótko: 5 linijek tekstu w pliku /.well-known/security.txt który mówi researcherowi bezpieczeństwa "jak znajdziesz dziurę na mojej stronie, napisz tutaj". Standard od 2017 roku, formalnie w RFC 9116 (2022). Google, Mozilla, Apple, GitHub, Cloudflare - wszyscy go mają.

Po co? Wyobraź sobie taki scenariusz. Ktoś znajduje XSS na Twojej stronie kontaktowej. Co robi?

Wariant 1: Szuka kontaktu. Nie znajduje. Wrzuca na Twitter "ej, ta strona ma XSS-a", i już jutro masz problem.

Wariant 2: Szuka kontaktu. Nie znajduje. Sprzedaje informację o dziurze na darknecie. Nawet się nie dowiesz, że masz problem, dopóki ktoś czegoś nie ukradnie.

Wariant 3: Szuka kontaktu. Znajduje na security.txt. Pisze mailem. Naprawiasz w tydzień. Wszyscy zadowoleni.

Pierwsze dwa scenariusze widziałem. Trzeci też. Różnica między nimi to 5 linijek tekstu na Twoim serwerze.

Wyniki audytu 12 hostingów

Sprawdziłem największych polskich graczy plus kilku zachodnich (OVH też ma .pl). Każdy adres głównej domeny hostingu, ścieżki standardowe: /.well-known/security.txt i /security.txt jako fallback. Wynik:

Mają security.txt:

home.pl - i to po królewsku. Mają pełny zestaw: Contact, Expires (do 2028), klucz PGP opublikowany na keys.openpgp.org, Preferred-Languages PL i EN. Konfiguracja na poziomie zachodnich tech-companies. Szacunek.

chcedointernetu.pl - nasza, dodaliśmy w trakcie pisania tego posta. RFC 9116, 3 kontakty (mail, formularz, telefon), Expires na 2027, polityka. Skromniej niż home.pl, ale jest.

Nie mają security.txt:

seohost.pl, zenbox.pl, cyber-folks.pl, dhosting.pl, mydevil.net, ovh.pl, nazwa.pl, smarthost.pl, lh.pl, kei.pl.

10 z 12. Czyli 83%.

Ironia: hosting który sprzedaje narzędzie do sprawdzania security.txt sam go nie ma

To nie jest tania zaczepka. seohost.pl ma w swoim panelu zarządzania klientów konkretne narzędzie do generowania raportu security.txt na ich stronach. Konkretny moduł, własna sekcja, zachęcanie klientów: "włącz, sprawdzaj, dodaj jeśli nie masz".

Po czym idziesz na seohost.pl i sprawdzasz - sami nie mają. Klasyk.

Nie mówię tego żeby się czepiać. Mówię to żeby pokazać, że nawet firmy które wiedzą o czymś i mają w ofercie narzędzia z tym związane, zapominają zrobić to u siebie. Łatwo wpaść w pułapkę "dodam jutro, jutro, jutro".

Skala fail-a u dużych

Pominę mniejszych. Ale popatrz na tę listę:

OVH - globalny gigant hostingu, miliony klientów, brak.

nazwa.pl - jeden z największych w Polsce, brak.

cyber-folks - aktywni w community, hostują dużo świadomych klientów, brak.

zenbox - nowoczesny stack, pewnie świadomi standardów, brak.

To nie jest "stara firma która zapomniała". To bardzo aktywni gracze. Po prostu nikt tego nie sprawdza, więc nikt tego nie ma. Standard niewymuszany.

Jak dodać u siebie (15 minut roboty)

Tworzysz plik tekstowy pod ścieżką /.well-known/security.txt na swoim serwerze. Zawartość minimalna to dwie linie:

Contact: mailto:twoj-mail@twojadomena.pl
Expires: 2027-06-16T00:00:00.000Z

Pole Contact mówi gdzie pisać. Pole Expires mówi do kiedy ten plik jest aktualny (max rok od dziś według RFC, ustawiasz przyszłą datę).

Wersja porządniejsza, tak jak mamy u siebie:

Contact: mailto:ratunku@chcedointernetu.pl
Contact: https://chcedointernetu.pl/#kontakt
Contact: tel:+48732067200
Expires: 2027-06-16T00:00:00.000Z
Preferred-Languages: pl, en
Canonical: https://chcedointernetu.pl/.well-known/security.txt
Policy: https://chcedointernetu.pl/polityka-prywatnosci

To wszystko. Wrzucasz na serwer, sprawdzasz że plik się otwiera w przeglądarce na adresie z .well-known. Gotowe.

Jeszcze jedna rzecz - warto dodać 301 redirect z /security.txt (bez .well-known) na ten canonical, bo niektóre stare skanery sprawdzają najpierw root. U nas tak mamy.

Co dalej

Pierwsze: sprawdź swoją stronę. Wejdź na twojadomena.pl/.well-known/security.txt. Jest? Świetnie. Nie ma? Wiesz co robić.

Drugie: sprawdź też swoich klientów albo swojego hostingodawcę. Możesz użyć naszego darmowego audytu GEO - od niedawna sprawdza również security.txt. Wynik dostajesz w 5 sekund.

Trzecie: jeśli prowadzisz agencję albo dział marketingu i robisz cokolwiek dla klientów, dodaj security.txt do listy "rzeczy które ogarniamy". To 15 minut roboty per strona, pokazuje że ogarniasz, i realnie chroni klienta. Mocna kombinacja.

A jeśli prowadzisz hosting i czytasz to późno w nocy, to wiesz co masz zrobić rano. ;)