security.txt (RFC 9116)

Biztonsági szempontból

A hibát megtaláló és a hibát javító ember között van egy szakadék. A info@ címre küldött levél az ügyfélszolgálaton landol, ahol senki nem tudja, mit kezdjen egy SQL-injection leírással. A security.txt ezt a szakadékot hidalja át.

A riportokban ezt látjuk: sok cégnél a biztonsági bejelentés végül a Facebook-oldal privát üzenetében érkezik meg. Ott hetekig áll.

SEO és AI szempontból

Rangsorolási hatása nincs. A Google nem olvassa, az AI-crawlerek sem indexelik érdemben. A hatás alacsony, ezt a riport is így jelöli.

Ami mégis számít: a fájl megléte egy gondozottsági jel. Ugyanabba a körbe tartozik, mint az impresszum, a adatvédelmi tájékoztató vagy a llms.txt és llms-full.txt. Ahol ezek megvannak, ott jellemzően a biztonsági fejlécek is rendben vannak.

Üzleti szempontból

A hatókör üzleti döntés: el kell döntened, hogy fogadsz-e bejelentéseket, és ki olvassa a postaládát. Egy válasz nélkül hagyott bejelentés rosszabb, mint a hiányzó fájl. Közbeszerzésnél és nagyvállalati beszállítói auditnál egyre gyakrabban kérdés.

Kikre vonatkozik

• Webshopokra, ahol fizetési és vásárlói adat van a rendszerben
• SaaS- és ügyfélportálokra, ahol bejelentkezés és felhasználói fiók van
• Közintézményi és egészségügyi oldalakra, ahol az adatkör érzékeny
• Minden oldalra, ahol van bárki, aki egy bejelentést el tud olvasni

Kikre nem

• Egyoldalas bemutatkozó oldalakra, ahol nincs űrlap és nincs bejelentkezés: itt tényleg opcionális
• Staging- és teszt-környezetekre: ezek noindex mögött vannak, nem is kellene elérhetőnek lenniük
• Aldomainekre külön, ha a fő domainen már fent van és a Canonical mező odamutat

Nyelvi megjegyzés

Magyar oldalnál érdemes a Preferred-Languages: hu, en mezőt kitenni. A magyar KKV-oldalak többségén ez a fájl egyáltalán nem létezik, pedig 10 perc alatt kész.

Lépések

1. Nyisd meg böngészőben a https://domain.hu/.well-known/security.txt címet.
2. Ha 404-et kapsz, próbáld a régi, elavult helyet is: https://domain.hu/security.txt.
3. Nézd meg a válasz Content-Type fejlécét devtoolsban vagy curl-lel: text/plain kell legyen.
4. Ellenőrizd az Expires mező dátumát: ha múltbeli, a fájl formailag lejárt.
5. Küldj egy próbalevelet a Contact mezőben szereplő címre, és nézd meg, hogy megérkezik-e.

Jó jel

• 200-as státuszkód a /.well-known/security.txt címen
• Content-Type: text/plain; charset=utf-8
• Van Contact és van jövőbeli Expires
• A Contact cím élő postaláda, amit valaki olvas

Rossz jel

• 404, vagy soft 404: a fájl helyett a hibaoldal HTML-je jön vissza
• Content-Type: text/html, mert a szerver rosszul szolgálja ki
• Lejárt Expires, gyakran 2-3 éves dátummal
• A Contact mezőben egy már megszűnt kolléga e-mail-címe

WordPress

1. FTP-n vagy fájlkezelőben hozz létre egy .well-known mappát a webroot alatt.
2. Tedd bele a security.txt fájlt.
3. Ellenőrizd, hogy a szerver nem tiltja a pontal kezdődő mappákat. Egyes tárhelyeken az Apache alapból blokkolja.
4. Ha blokkolva van, a .htaccess-be vedd fel kivételként.
5. Alternatíva plugin nélkül: egy add_action('init') hook, ami a kérést elkapja és kiírja a tartalmat.

Shopify

A Shopify nem enged tetszőleges fájlt a /.well-known/ alá. Két út van:

1. Ha saját domainen vagy és a DNS/CDN réteg a tiéd, ott old meg egy átirányítással vagy worker-rel.
2. Ha nem, tedd ki a kontaktot egy /pages/security oldalra, és hivatkozz rá az impresszumból.

Unas

Az Unas webáruház SaaS-rendszer, a webroot nem a tiéd. Nyiss ticketet a rendszergazdáknak, és kérd a fájl kihelyezését. Ha ez nem járható, a /security aloldal a gyakorlati minimum.

Shoprenter

Ugyanaz a helyzet, mint az Shoprenternél általában: a platform-szintű fájlokhoz támogatás kell. Kérd a /.well-known/security.txt kiszolgálását, hivatkozva az RFC 9116-ra.

Egyedi fejlesztés

1. Tedd a fájlt statikusan a webroot .well-known könyvtárába.
2. Nginx-nél add hozzá a location = /.well-known/security.txt { default_type text/plain; } blokkot.
3. Állítsd be az Expires mezőt maximum 1 évre előre.
4. Vedd fel a naptáradba az éves frissítést, különben lejár.
5. Ha CDN előtt van, ellenőrizd, hogy a cache nem szolgál ki régi verziót.

Mit néz ebből a riport

Az audit lekéri a /.well-known/security.txt címet, és megnézi, hogy 200-as választ kap-e szöveges tartalommal. Ellenőrzi, hogy szerepel-e benne Contact mező. Hiány esetén alacsony hatású javaslatot ad, mert ez üzleti döntés, nem kódhiba.

• A fájl a webroot gyökerében van, nem a .well-known alatt - az RFC 9116 szerint a /security.txt elavult hely, a szkennerek a .well-known verziót keresik.
• Hiányzik vagy lejárt az Expires mező - a szabvány kötelezővé teszi, lejárt dátum esetén a fájl formailag érvénytelen.
• HTML jön vissza text/plain helyett - a szerver a 404-oldalt adja, és az automatizált ellenőrzések ezt hibának látják.
• A Contact mezőben egy űrlap URL-je van, ami sütiket kér - egy bejelentő nem fog cookie-bannerrel küzdeni, tegyél melléje mailto: címet is.
• A megadott postaládát senki nem olvassa - a válasz nélkül hagyott bejelentés bizalmi kár, rosszabb, mint a hiányzó fájl.
• A fájlt a robots.txt Disallow szabálya letiltja - a robots.txt amúgy sem véd semmit, de itt konkrétan akadályt jelent.
• Titkosítási kulcsra mutat a Encryption mező, ami már lejárt - a bejelentő nem tud titkosítva küldeni, és ezt te nem veszed észre.

Minimális, szabványos fájl a /.well-known/security.txt címen:

Contact: mailto:security@pelda.hu
Contact: https://pelda.hu/biztonsag
Expires: 2027-01-01T00:00:00.000Z
Preferred-Languages: hu, en
Canonical: https://pelda.hu/.well-known/security.txt
Policy: https://pelda.hu/biztonsagi-szabalyzat

A Contact lehet többszörös, a sorrend a preferenciát jelzi. Az Expires ISO 8601 formátumú, jövőbeli dátum.

Ellenőrzés parancssorból, a fejlécekkel együtt:

curl -sI https://pelda.hu/.well-known/security.txt
curl -s https://pelda.hu/.well-known/security.txt

Az első parancs a státuszkódot és a Content-Type fejlécet mutatja. A másodikban a fájl tartalmát látod. Ha HTML-t kapsz vissza, a szerver a hibaoldalt szolgálja ki, és a fájl valójában nincs kint.

Nginx-konfiguráció a helyes MIME-típushoz:

location = /.well-known/security.txt {
    default_type text/plain;
    charset utf-8;
}