X-Content-Type-Options

Biztonsági hatás

A MIME-sniffing tipikus támadási útvonala a felhasználói feltöltés. Ha az oldalad engedi a képfeltöltést, és a fájlt a saját domainedről szolgálod ki, a sniffing nélküli böngésző egy HTML-be csomagolt kép-fájlt weboldalként renderelhet. Onnan a script a te domainednél fut, a te sütijeiddel.

A második eset a beavatkozás a válaszba. Rosszul beállított CDN vagy proxy néha átírja a típust. A nosniff itt is véd: nincs mozgástér a böngészőnek.

Audit- és megfelelőségi hatás

A Lighthouse Best Practices és a legtöbb fejléc-ellenőrző eszköz külön tételként hozza. A hiánya önmagában nem kritikus, de:

• rontja a biztonsági pontszámot minden auditban,
• feltűnik a partneri és beszállítói biztonsági kérdőíveken,
• nagyvállalati beszerzésnél konkrét visszadobási ok lehet.

SEO és üzleti következmény

Rangsorolási tényező nem. Közvetett hatása viszont van. Egy XSS-en keresztül befecskendezett spam-tartalom az index-szennyezés leggyakoribb kiindulópontja. Amikor a Google spam-oldalakat indexel a domainedről, a helyreállítás hetekbe kerül.

A riportokban azt látjuk, hogy a hiányzó nosniff szinte mindig együtt jár hiányzó HSTS (HTTP Strict Transport Security)-sel és X-Frame-Options-szal. Nem egy fejléc hiányzik, hanem az egész réteg.

Vonatkozik minden HTTP-választ kiszolgáló oldalra. Nincs olyan oldaltípus, ahol a nosniff kárt okozna, ha a szerver helyesen adja meg a típusokat.

Különösen fontos ott, ahol:

• felhasználók tölthetnek fel fájlt: webshop termékkép, profilkép, CV-feltöltés, ügyfélportál,
• user-generated tartalom van: fórum, kommentek, értékelések,
• bejelentkezés van: ahol sütit lehet ellopni, ott valódi a tét,
• fizetés zajlik: a PCI-DSS-hez kapcsolódó ellenőrzések rendszeresen kérik.

Kevésbé sürgős, de ugyanúgy ajánlott:

• statikus bemutatkozó oldalakon, ahol nincs feltöltés és nincs login,
• landing page-eken, kampányoldalakon.

Staging és fejlesztői környezet: ugyanúgy állítsd be, mint az éles oldalon. Ha csak élesben kapcsolod be, a MIME-típus hibák éles indulás után derülnek ki. A staging oldalt egyébként noindex-szel és jelszóval is zárd le.

Kivétel nincs, de figyelj: ha az oldalon régi, rosszul konfigurált fájlkiszolgálás van (például .php kiterjesztésű JS-generátor text/html típussal), előbb a típusokat javítsd.

1. Böngésző devtools

1. Nyisd meg az oldalt, és nyomj F12-t.
2. Válaszd a Network fület, majd frissíts.
3. Kattints a lista legelső, HTML-dokumentum kérésére.
4. A Headers panelen keresd a Response Headers szakaszt.
5. Nézd meg, szerepel-e ott az x-content-type-options.

2. curl parancssorból

Ez a leggyorsabb módszer, ha több URL-t nézel:

curl -sI https://pelda.hu | grep -i x-content-type-options

Üres válasz azt jelenti, hogy nincs beállítva.

3. Lighthouse

Futtass Lighthouse auditot Chrome-ból vagy a PageSpeed Insights felületéről. A Best Practices blokkban van egy tétel a biztonsági fejlécekről. A nosniff hiánya ott is megjelenik.

Jó jel

• x-content-type-options: nosniff szerepel a válaszban.
• Minden aloldalon ott van, nem csak a főoldalon.
• A statikus fájloknál (CSS, JS, kép) is megjelenik.
• A JS-fájlok Content-Type-ja text/javascript, a CSS-eké text/css.

Rossz jel

• A fejléc teljesen hiányzik.
• Az érték nem pontosan nosniff (elgépelés, no-sniff, 1).
• Kétszer szerepel, eltérő értékkel: ilyenkor a szerver és az alkalmazás is beleír.
• Csak a főoldalon van meg, a /kosar vagy /admin útvonalon nincs.

Mit néz ebből a riport

Az audit lekéri a főoldal válaszfejléceit, és megnézi, szerepel-e az X-Content-Type-Options: nosniff. Ha hiányzik, a biztonsági blokkban jelzi, jellemzően a többi alapfejléccel együtt. A javítás általában egy szerverkonfigurációs sor, ezért a riport gyors győzelemként sorolja be.

WordPress

A legtisztább megoldás a webszerver szintjén állítani, nem pluginnel.

Apache (.htaccess a gyökérben):

<IfModule mod_headers.c>
  Header always set X-Content-Type-Options "nosniff"
</IfModule>

Nginx (a server blokkban):

add_header X-Content-Type-Options "nosniff" always;

Ha nem férsz a konfighoz, a functions.php-ban is beállítható:

add_action('send_headers', function () {
    header('X-Content-Type-Options: nosniff');
});

Sok biztonsági plugin (Wordfence, Really Simple Security) kapcsolóval kínálja. Csak egy helyen kapcsold be, különben duplázódik a fejléc.

Shopify

A Shopify alapból küldi a nosniff fejlécet minden bolt-válaszban. Nincs teendőd, és nem is tudod kikapcsolni. Ellenőrizni érdemes curl-lel, ha egyedi domain vagy reverse proxy van előtte.

Unas

Az Unas platformszinten kezeli a válaszfejléceket, a bolt-tulajdonos nem tudja szerkeszteni. Ellenőrizd curl-lel. Ha hiányzik, az ügyfélszolgálatnál jelezd. A sablonba szúrt <meta http-equiv> nem helyettesíti a valódi fejlécet.

Shoprenter

A Shoprenter esetében is a platform adja a fejléceket. Saját domain és külső CDN használatakor a CDN felülírhatja őket. Mérd meg a valódi éles URL-en.

Egyedi fejlesztés

1. Döntsd el, hol legyen az egyetlen forrás: webszerver, reverse proxy vagy alkalmazás. Ne két helyen.
2. Állítsd be globálisan, minden útvonalra, a statikus fájlokat is beleértve.
3. Laravel: middleware-ben vagy a TrustProxies után, $response->headers->set('X-Content-Type-Options', 'nosniff').
4. Node/Express: a helmet csomag alapból bekapcsolja a noSniff opciót.
5. Telepítés után kérd le curl-lel az összes fő oldaltípust: főoldal, kategória, termék, kosár, admin.
6. Nyisd meg a devtools Console fülét, és keresd a blokkolt erőforrásokra utaló hibákat.

Ha a bekapcsolás után eltörik egy script, ne a fejlécet vedd ki. Javítsd a Content-Type-ot annál a fájlnál.

Ha CDN van előtte

A CDN gyakran nem adja tovább az origin fejléceit, vagy saját fejléceket ad. Cloudflare-nél a Transform Rules vagy egy Worker használható. Mindig a nyilvános URL-t mérd, ne az origint.

• Meta tag a fejléc helyett: a <meta http-equiv="X-Content-Type-Options"> nem működik, a böngésző csak a valódi HTTP-fejlécet fogadja el.
• Csak a főoldalon van beállítva: a virtuális host helyett egy location blokkba került, így a belső oldalak és a statikus fájlok védtelenek maradnak.
• Nginxnél hiányzik az always kulcsszó: enélkül a hibaoldalak (404, 500) válaszaiból kimarad a fejléc.
• Nginxnél az add_header öröklődési csapdája: ha egy belső blokkban is van add_header, a külső szint összes fejléce elveszik abban a blokkban.
• Dupla fejléc plugin és szerverkonfig miatt: két helyről érkezik ugyanaz, ami zavaró a debugolásnál és egyes proxykat megakaszt.
• A fejléc kiszedése, amikor eltörik egy script: a valódi hiba a rossz Content-Type, a fejléc csak megmutatta.
• A magyar KKV-oldalak többségén egyáltalán nincs beállítva: nem konkrét döntés eredménye, egyszerűen soha nem került szóba a fejlesztés során.

A helyes válaszfejléc

HTTP/2 200
content-type: text/html; charset=UTF-8
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
referrer-policy: strict-origin-when-cross-origin
strict-transport-security: max-age=31536000; includeSubDomains

Egyetlen érvényes érték a nosniff. Minden más értéket a böngésző figyelmen kívül hagy, illetve hibás konfigurációként kezel.

Ellenőrzés több URL-en

for u in / /kategoria/ /termek/teszt /kosar; do
  echo "--- $u"
  curl -sI "https://pelda.hu$u" | grep -iE 'content-type|x-content-type-options'
done

A kimenetben két dolgot nézz. Szerepel-e a nosniff, és helyes-e a content-type az adott erőforráson.

Teljes Apache-blokk az alapfejlécekkel

<IfModule mod_headers.c>
  Header always set X-Content-Type-Options "nosniff"
  Header always set X-Frame-Options "SAMEORIGIN"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>

Ez a három fejléc együtt telepíthető, egyiknek sincs tartalmi mellékhatása. A CSP ennél összetettebb: azt külön, tesztelve vezesd be.