Defaults.Exposed › Oplossingen › MIME-sniffing-bescherming (X-Content-Type-Options)

Hoe je MIME-sniffing-bescherming (X-Content-Type-Options) oplost

Eén regel header die browsers belet te raden wat een bestand werkelijk is. Zonder haar kan een bestand dat iemand naar uw site uploadt — of een bestand op uw eigen pagina's — verkeerd worden gelezen door de browser en als code worden uitgevoerd, en precies zo veranderen sommige aanvallen een onschuldig ogende upload in een manier om de sessies van uw klanten te stelen.

De kern voor je bedrijf: Het ontbreken van deze header is een duidelijk, scanbaar teken dat de basis niet op orde is. Op zichzelf legt het zelden een site plat, maar gecombineerd met een uploadformulier of door gebruikers aangeleverde inhoud opent het een pad voor een aanvaller om kwaadaardige code uit te voeren in de browsers van uw bezoekers — ingelogde sessies kapen, kaart- of inloggegevens stelen, en u aan de verkeerde kant van een datalekgesprek zetten. Het is een van de goedkoopste oplossingen in beveiliging: één regel, gratis, zo'n vijf minuten.

Wat dit je kan kosten

• Elke pagina waar klanten of medewerkers bestanden kunnen uploaden (avatars, documenten, supportbijlagen, advertentiefoto's) wordt een mogelijke lanceerbasis voor browsergerichte aanvallen.
• Een aanvaller kan kwaadaardige code vermommen als een afbeelding of tekstbestand en die door de browser van de bezoeker laten uitvoeren — waarmee diens ingelogde sessie op uw site wordt gestolen.
• Securityvragenlijsten, cyberverzekeringscontroles en zakelijke kopers scannen op deze header; de afwezigheid leest als „ze doen de basis niet” en kan een deal vertragen of laten kelderen.
• Oudere browsers en sommige integraties „sniffen” contenttypes en kunnen bestanden verkeerd verwerken op manieren die vertrouwen schaden of data lekken.

Waarom het ertoe doet. Wanneer een server vaag is over wat een bestand is, proberen browsers het te raden („sniffen”) van het contenttype. Aanvallers misbruiken die gok: ze uploaden een bestand dat de server als afbeelding labelt, maar maken de inhoud zo dat de browser besluit dat het eigenlijk JavaScript is — en het uitvoert. De X-Content-Type-Options: nosniff-header zegt elke browser het raden te stoppen en het door de server opgegeven type te vertrouwen, waarmee die hele categorie truc wordt dichtgegooid. Het is een gescoorde check, 25 punten waard, en krijgt middelhoge ernst wanneer ze ontbreekt.

De korte versie voor de eigenaar

In elke webbrowser zit een stille aanname: wanneer hij een bestand van uw site downloadt, probeert hij uit te zoeken wat voor soort bestand het is. Meestal vertrouwt hij uw server. Maar als uw server vaag is, gaat de browser raden — en dat raden heet MIME-sniffing.

Het probleem is dat aanvallers de gok kunnen manipuleren. Ze kunnen een bestand maken dat uw server eerlijk voor een onschuldige afbeelding houdt, maar dat de browser, als hij mag raden, besluit dat het eigenlijk een stuk programmacode is — en het dan uitvoert, midden in de browser van uw klant, op uw domein.

Er is één regel instructie die het raden uitschakelt: X-Content-Type-Options: nosniff. Die zegt elke browser: „niet raden — vertrouw precies wat mijn server je vertelt.” Dat is de hele oplossing. Het is gratis, kost zo’n vijf minuten, en op een goed gebouwde site breekt het niets.

Deze check zoekt naar die header. Ontbreekt hij, dan verliest u 25 punten en krijgt het middelhoge ernst — niet omdat de header alleen een ramp is, maar omdat de afwezigheid een betrouwbaar teken is dat de basis niet is afgegrendeld.

Wat dit u kan kosten

Dit zijn realistische scenario’s op bedrijfsniveau — geen rampdramatiek.

• De „onschuldige bijlage” die het niet was. U draait een supportportaal of een marktplaats waar klanten bestanden uploaden — bonnen, foto’s, documenten. Een aanvaller uploadt een bestand dat uw systeem opslaat en als afbeelding serveert. Zonder nosniff raadt de browser van een slachtoffer dat het bestand eigenlijk een script is en voert het uit — en steelt stilletjes de ingelogde sessie van die bezoeker op uw site. Nu is de aanvaller hen: bestellingen plaatsen, berichten lezen, gegevens wijzigen. U komt erachter wanneer klanten gaan klagen over activiteit die ze niet deden.

• De deal die vastloopt op een securityvragenlijst. Het inkoopteam van een grotere klant draait vóór ondertekening een geautomatiseerde scan van uw site. Ontbrekende securityheaders verschijnen meteen. Zelfs als er nooit iets misbruikt is, zegt het rapport „basale websecurityheaders afwezig”, en plots beantwoordt u remediatievragen en schuift uw sluitdatum weken op — over een oplossing die vijf minuten had gekost.

• De cyberverzekeringsverlenging die lastiger wordt. Steeds meer verzekeraars draaien externe scans vóór een offerte of verlenging. Een schoon headerprofiel is goedkoop bewijs van hygiëne; een ontbrekende is een kleine smet die, opgestapeld met andere, uw premie omhoog of uw voorwaarden omlaag duwt.

• De reputatieschade die u niet zomaar ongedaan maakt. Als een sessiekaping te herleiden is naar een bestand dat vanaf uw domein werd geserveerd, is het verhaal niet „een obscure header ontbrak” — het is „[uw bedrijf] lekte klantaccounts.” Dat is de versie die klanten onthouden, en die kost veel meer dan de oplossing ooit zou doen.

Geen van deze vereist een geraffineerde aanvaller. Misbruik van MIME-sniffing is goed begrepen en geautomatiseerd, en precies daarom markeren scanners de ontbrekende header zo stellig.

Wat het feitelijk is

Wanneer een browser een bestand ontvangt, hoort de server het te labelen met een contenttype (bijvoorbeeld image/png voor een PNG-afbeelding of text/html voor een webpagina). Historisch vertrouwden browsers dat label niet volledig — deels omdat sommige servers het verkeerd deden — dus gluurden ze naar de werkelijke bytes van het bestand en besloten zelf. Dat gluren is MIME-sniffing.

Het was een gemak dat een gevaar werd. Als een aanvaller een bestand op uw site krijgt (via een uploadformulier, een reactieveld, een geïmporteerd document) en de inhoud kan beïnvloeden, kan hij iets maken dat de server onschuldig labelt maar de browser als uitvoerbaar script sni’t. De browser draait het dan op uw domein, met alle vertrouwen dat uw domein draagt.

X-Content-Type-Options: nosniff haalt het giswerk er volledig uit. Met deze instelling krijgt de browser te horen: gebruik het door de server opgegeven type en niets anders. Een bestand dat als afbeelding is gelabeld, wordt als afbeelding behandeld, punt — ook al ziet de inhoud eruit als script. Het aanvalspad sluit.

Hoe „goed” eruitziet: elke response van uw site — pagina’s en assets — draagt precies deze header:

X-Content-Type-Options: nosniff

Er is geen andere geldige waarde en niets bij te stellen. Voegen uw CDN én uw server hem allebei toe (zodat u nosniff, nosniff ziet), dan is dat prima en geldt nog steeds als geslaagd.

Hoe los je het op (gratis, ~5 minuten)

Geef dit onderdeel aan wie uw website beheert — uw IT’er, webontwikkelaar of hostingsupport. De oplossing is gratis en snel; er valt niets te kopen. Wat u vraagt is eenvoudig: „Voeg de response-header X-Content-Type-Options: nosniff toe aan elke pagina en elk asset op de site.”

Hier het detail voor hen, per gangbaar platform.

Cloudflare (of een vergelijkbaar CDN/proxy) — vaak de snelste plek, dekt de hele site in één keer:

• Gebruik een Response Header Transform Rule (Rules → Transform Rules → Modify Response Header) om X-Content-Type-Options op nosniff te zetten voor alle binnenkomende verzoeken. Dit past het sitebreed toe zonder de origin-server aan te raken.

Nginx — voeg toe binnen het relevante server- (of location-)blok:

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

Het sleutelwoord always zorgt dat hij ook bij foutresponses wordt meegestuurd. Herlaad Nginx na het opslaan.

Apache — vereist mod_headers; in de siteconfig of .htaccess:

Header always set X-Content-Type-Options "nosniff"

IIS / Windows-hosting — in web.config onder <system.webServer>:

<httpProtocol>
  <customHeaders>
    <add name="X-Content-Type-Options" value="nosniff" />
  </customHeaders>
</httpProtocol>

Node / Express — stel hem voor elke response in:

app.use((req, res, next) => {
  res.setHeader('X-Content-Type-Options', 'nosniff');
  next();
});

(Of gebruik het helmet-pakket, dat deze en diverse andere securityheaders standaard instelt.)

Google Workspace / Microsoft 365-sites: deze beheren uw e-mail en documenten, niet uw publieke websitehosting, dus de header wordt daar niet ingesteld — hij wordt ingesteld waar uw website zelf wordt geserveerd (uw CDN, webserver of sitebouwer). Gebruikt u een gehoste sitebouwer (Squarespace, Wix, Shopify en dergelijke), dan voegen velen deze header automatisch toe; controleer het resultaat in plaats van aan te nemen, en vraag hun support als hij ontbreekt.

Verifieer na het uitrollen. Draai uw scan opnieuw, of laat uw ontwikkelaar de response-headers in de devtools van de browser controleren (tabblad Network → klik op een verzoek → Response Headers) en bevestigen dat X-Content-Type-Options: nosniff aanwezig is. Test de site even om te bevestigen dat niets met opmaak of script brak — op een correct gebouwde site breekt er niets.

Veelgemaakte fouten

• Hem alleen op de homepage zetten. De header moet op elke response staan — ook afbeeldingen, scripts, stylesheets en geüploade bestanden — want dat zijn de bronnen die sniffing treft. Pas hem toe op server- of CDN-niveau zodat hij universeel is, niet pagina voor pagina.
• Een typefout in de waarde. De enige geldige waarde is nosniff. Iets anders (een lege waarde, een spelfout) laat de check zakken en biedt geen bescherming. De scanner rapporteert de waarde die hij werkelijk zag, zodat u een typefout kunt opsporen.
• Aannemen dat het een Content Security Policy vervangt. nosniff is één laag. Het regelt niet welke scripts mogen draaien — dat is de taak van CSP. Voeg nosniff nu toe als snelle winst, en behandel een degelijke CSP als de grotere vervolgstap.
• Het „duplicaat” verwijderen. Stellen zowel uw CDN als origin hem in, dan ziet u hem tweemaal. Dat is onschadelijk — verspil geen tijd aan het wegstrippen van één.
• Ervoor betalen. Het is een gratis configuratiewijziging. Monitoring, audits en portefeuilledashboards zijn terecht betaald; één header toevoegen niet.

Geef dit aan uw IT’er

De technische samenvatting: deze check inspecteert de HTTP-response-headers en slaagt wanneer X-Content-Type-Options aanwezig is en de (niet-hoofdlettergevoelige) waarde nosniff bevat — inclusief het multi-bron-geval nosniff, nosniff waar een CDN en origin hem allebei instellen. Ontbrekend of elke niet-nosniff-waarde zakt. Het is een gescoorde P2-check, 25 punten waard, middelhoge ernst bij falen, en gekoppeld aan OWASP Top 10 A05 (Security Misconfiguration). De remediatie is één statische response-header toegepast over alle responses; er zijn geen parameters en geen geldige alternatieve waarden. Stel hem in aan de rand (CDN) voor sitebrede dekking, of bij de webserver met always-semantiek zodat hij ook bij foutresponses wordt uitgestuurd, en bevestig daarna in de response-headers.

Veelgestelde vragen