Defaults.Exposed › Oplossingen › Clickjacking-bescherming (X-Frame-Options)

Hoe je Clickjacking-bescherming (X-Frame-Options) oplost

Eén regel instructie die browsers vertelt dat andere websites uw site niet stiekem in hun eigen pagina mogen laden. Zonder deze instructie kan een oplichter uw echte, ingelogde pagina's verbergen achter een nepscherm en uw klanten dingen laten aanklikken die ze nooit bedoeld hebben — een betaling goedkeuren, een wachtwoord wijzigen, toegang verlenen.

De kern voor je bedrijf: Een fraudeur kan uw echte website onzichtbaar in een neppagina verpakken en geld of accounttoegang stelen van uw ingelogde klanten — en voor de klant lijkt het alsof uw site dat deed. De oplossing is gratis en kost een ontwikkelaar zo'n 15 minuten; het achterwege laten is een bekend gat dat zowel criminelen als voorzichtige kopers binnen enkele seconden zien.

Wat dit je kan kosten

• Een oplichter verbergt uw echte inlog- of betaalscherm achter een onschuldig ogende pagina en laat een klant een overschrijving of instellingswijziging bevestigen zonder dat die het doorheeft — de klant geeft u de schuld, niet de aanvaller.
• Uw ingelogde accountomgeving wordt onzichtbaar geladen bovenop een pagina als „U heeft gewonnen — klik om te claimen”; de klik keurt in werkelijkheid een echte wijziging op het account van de klant goed, en u krijgt het boze supportgesprek.
• Het IT-team van een prospect draait vóór ondertekening een snelle securityscan, ziet dat uw site door iedereen kan worden ingebed, en markeert dat als een risico dat de deal vertraagt of laat klappen.
• Uw merk wordt het lokaas in een fraudecampagne; klanten die erin trappen onthouden u als „het bedrijf waarvan de site dit liet gebeuren”.
• Een auditor of cyberverzekeringsscan noemt het ontbreken van clickjacking-bescherming als een basishygiënefout — goedkoop te verhelpen, gênant om aangemerkt te krijgen.

Waarom het ertoe doet. Dit is een gratis instelling van één regel die in enkele minuten is toegevoegd en een hele categorie misleiding gericht op uw ingelogde klanten dichtgooit. In onze scoring is dit een websecuritycheck die echte punten waard is met hoge ernst, want een ontbrekende header laat een bekend, makkelijk te controleren gat open dat criminelen automatiseren en kopers opzoeken.

Wat dit is, in gewone woorden

Wanneer iemand uw website bezoekt, kan zijn browser ook de opdracht krijgen om uw site binnen een andere website te laden — als een klein venster ingebed in een grotere pagina. Dat klinkt onschuldig, en soms is het dat ook. Maar het is het mechanisme achter een aanval genaamd clickjacking.

Dit is de truc. Een oplichter bouwt een eigen pagina en laadt daarin stilletjes uw echte website — onzichtbaar, volledig transparant gemaakt. Daaroverheen legt hij zijn eigen inhoud: een opvallende knop, een „Speel video af”, een „Claim je prijs”. Uw klant ziet de pagina van de aanvaller en klikt op wat een onschuldige knop lijkt. Maar omdat uw echte site onzichtbaar onder de cursor zit, landt de klik in werkelijkheid op uw pagina — een betaling bevestigen, een wachtwoord wijzigen, toegang goedkeuren, een toestemming aanvaarden. De klant denkt het ene aan te klikken; in werkelijkheid klikt hij iets anders, op een site die hij vertrouwt.

Clickjacking-bescherming is een korte, onzichtbare instructie die uw website naar de browser van elke bezoeker stuurt en die in feite zegt:

„Laat andere websites mij niet binnen zich laden. Als iemand het probeert, weiger.”

Moderne browsers gehoorzamen dit automatisch. Met de bescherming aan werkt de truc simpelweg niet — de ingesloten kopie van uw site weigert te laden. Zonder haar is uw site vrij wild om als verborgen laag in een zwendel te worden gebruikt, en de klant die erin trapt verbindt het hele voorval met uw merk, niet dat van de aanvaller.

Wat dit u kan kosten

Dit zijn realistische, alledaagse scenario’s. We noemen nooit een echt bedrijf; dit zijn illustraties van hoe het gat wordt misbruikt.

1. De onzichtbare „bevestigen”. Een klant is in één tabblad ingelogd op uw accountportaal. Hij belandt op een pagina (via een advertentie, een e-mail, een zoekresultaat) die iets verleidelijks belooft en een grote knop „Doorgaan” toont. Verborgen onder die knop zit uw echte knop „Overschrijving bevestigen” of „E-mail wijzigen”, geladen vanuit zijn eigen ingelogde sessie. Hij klikt „Doorgaan” — en autoriseert onbewust een wijziging op zijn echte account bij u. Voor hem, en voor uw supportteam, lijkt het alsof hij het deed op uw site.

2. De instellingenkaping. Een aanvaller framet uw pagina met accountinstellingen en legt daaroverheen een onschuldig spelletje of enquête. Een paar klikken op de juiste plekken verzetten stilletjes een instelling — het e-mailadres van de aanvaller toevoegen als herstellingsadres, een app-toestemming verlenen, of een beveiligingswaarschuwing uitschakelen. Het account is nu stilletjes gecompromitteerd, en niets leek op dat moment verkeerd.

3. De deal die vastloopt. Een grotere klant stuurt vóór ondertekening zijn standaard securityvragenlijst. Eén regel vraagt of uw site anti-framing-bescherming instelt (X-Frame-Options / CSP frame-ancestors). Uw IT-contact moet „nee” antwoorden, en de inkoop pauzeert terwijl u een gratis instelling van 15 minuten haastig regelt die nu als een rode vlag voor een koper staat.

4. De merk-als-lokaas-campagne. Omdat uw echte, vertrouwde pagina’s kunnen worden ingesloten, gebruikt een aanvaller uw inlog of afrekenscherm als overtuigende laag in een bredere phishingcampagne. De klanten die erin trappen geven niet de schimmige aanvaller de schuld — ze onthouden het als de keer dat „uw site” hen liet oplichten.

5. De auditmarkering. Een verzekeraarsscan, of een auditor die uw beveiligingshouding beoordeelt, vermeldt het ontbreken van clickjacking-bescherming tussen de bevindingen. Het is een schoolvoorbeeld van basishygiëne; aangemerkt worden signaleert dat de makkelijke, gratis beschermingen niet op orde waren — wat kleurt hoe de rest van uw beveiliging wordt beoordeeld.

De rode draad: de schade landt op een echte, ingelogde klant die iets doet wat hij niet bedoelde — en die draagt uw naam, niet die van de aanvaller.

Wat het feitelijk is

Wanneer een browser uw website om een pagina vraagt, stuurt uw server de pagina terug plus enkele onzichtbare „headers” — extra instructies die de browser leest maar de bezoeker nooit ziet. Clickjacking-bescherming wordt via deze headers geleverd. Er zijn er twee, en onze check slaagt als een van beide aanwezig is:

1. De oudere header — X-Frame-Options:

X-Frame-Options: SAMEORIGIN

Dit is de al lang bestaande, breed ondersteunde besturing. Ze neemt een van twee praktische waarden aan:

• SAMEORIGIN — uw eigen site mag zijn eigen pagina’s insluiten, maar geen enkele externe site. De veilige standaard voor vrijwel iedereen.
• DENY — niemand mag uw pagina’s insluiten, ook u niet. Gebruik dit alleen als uw site nooit zijn eigen inhoud framet.

2. De moderne header — Content-Security-Policy frame-ancestors:

Content-Security-Policy: frame-ancestors 'self';

Dit is de nieuwere, flexibelere besturing en degene waar huidige standaarden naar verwijzen. Ze doet hetzelfde werk maar laat u precies bepalen wie u mag insluiten:

• frame-ancestors 'self' — gelijk aan SAMEORIGIN.
• frame-ancestors 'none' — gelijk aan DENY.
• frame-ancestors 'self' https://partner.example.com — uw eigen site plus één genoemde, vertrouwde partner, en niemand anders.

Hoe „goed” eruitziet

De sterkste opzet gebruikt beide: frame-ancestors voor moderne browsers (en voor de precisie om toegestane insluiters te benoemen) en X-Frame-Options: SAMEORIGIN als terugvaloptie voor oudere clients. Onze check is tevreden met elk van beide op zichzelf — maar omdat beide gratis zijn en dezelfde paar minuten kosten, is er geen reden om ze niet allebei in te stellen.

Eén belangrijk detail dat uw ontwikkelaar moet weten: een Content-Security-Policy-Report-Only-header dwingt niets af — die rapporteert alleen. Als u wilt dat clickjacking-bescherming daadwerkelijk effect heeft, moet ze komen van een afdwingende header (een gewone Content-Security-Policy met frame-ancestors, of X-Frame-Options), niet van een report-only-versie.

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

Geef dit onderdeel aan wie uw website beheert — uw IT’er, webontwikkelaar of hostingsupport. De oplossing is gratis. Het zijn een of twee response-headers, of een regel in uw CDN. Er valt niets te kopen.

De check slaagt wanneer ofwel een X-Frame-Options-header (op DENY of SAMEORIGIN) ofwel een CSP frame-ancestors-richtlijn aanwezig is. De aanbevolen, dubbel uitgevoerde opzet voegt beide toe.

Stap 1 — Bepaal hoe streng

• De meeste bedrijven: SAMEORIGIN / frame-ancestors 'self'. Uw eigen site blijft werken; buitenstaanders worden geblokkeerd.
• Als uw site nooit zijn eigen pagina’s insluit: DENY / frame-ancestors 'none' voor maximale afgrendeling.
• Als een echte partner een specifieke pagina moet insluiten: benoem hem expliciet met frame-ancestors 'self' https://partner.example.com; en niemand anders komt erin.

Stap 2 — Voeg de headers toe (kies uw platform)

Nginx — binnen uw server-blok:

add_header X-Frame-Options "SAMEORIGIN" always;
add_header Content-Security-Policy "frame-ancestors 'self';" always;

Apache — zorg dat mod_headers aanstaat, dan in uw virtual host:

Header always set X-Frame-Options "SAMEORIGIN"
Header always set Content-Security-Policy "frame-ancestors 'self';"

Microsoft IIS — in web.config binnen <customHeaders>:

<add name="X-Frame-Options" value="SAMEORIGIN" />
<add name="Content-Security-Policy" value="frame-ancestors 'self';" />

Cloudflare (of een vergelijkbaar CDN): ga naar Rules → Transform Rules → Modify Response Header, en voeg twee regels toe die X-Frame-Options op SAMEORIGIN en Content-Security-Policy op frame-ancestors 'self'; zetten voor alle responses. Dit is de makkelijkste route als u geen directe servertoegang heeft.

Stuurt u al een Content-Security-Policy om andere redenen? Maak geen tweede CSP-header — voeg frame-ancestors toe aan uw bestaande policy. Twee CSP-headers kunnen botsen.

Websitebouwers (Squarespace, Wix, Shopify en dergelijke): deze platforms stellen anti-framing-bescherming vaak voor u in, dus mogelijk slaagt u al zonder iets te doen. Markeert onze check het toch, dan zit de besturing meestal in de beveiligingsinstellingen van het platform, of voegt u haar toe bij het CDN vóór de site. (Let op: Google Workspace en Microsoft 365 voeden uw e-mail, niet uw website — deze header stelt u in waar uw publieke site echt draait, niet in de Workspace/365-beheeromgeving.)

Stap 3 — Herladen en verifiëren

Herlaad de webserver of rol de CDN-regel uit, laad daarna uw live site en controleer de response-headers — devtools van de browser → tabblad Network → klik op het paginaverzoek → Response Headers, of een gratis header-checktool. Bevestig dat de header(s) verschijnen op echte paginaresponses, niet alleen op de homepage. Draai dan de check opnieuw.

Veelgemaakte fouten

• Een report-only-CSP gebruiken en aannemen dat die u beschermt. Content-Security-Policy-Report-Only rapporteert alleen overtredingen — dwingt niets af. U heeft een afdwingende header nodig om de bescherming te laten werken.
• Twee aparte Content-Security-Policy-headers instellen. Heeft u al een CSP, voeg er dan frame-ancestors aan toe in plaats van een tweede policy uit te sturen; botsende CSP-headers kunnen onverwacht gedrag geven.
• DENY instellen terwijl uw eigen site zijn eigen pagina’s insluit. DENY blokkeert alle framing, ook die van uzelf. Gebruikt een deel van uw site iframes van zichzelf, gebruik dan SAMEORIGIN / frame-ancestors 'self', anders breekt u uw eigen pagina’s.
• Alleen de homepage beschermen. De pagina’s die voor clickjacking het belangrijkst zijn, zijn de ingelogde — accountinstellingen, betaalbevestiging, beheer. Zorg dat de headers sitebreed worden toegepast, niet alleen op de voorpagina.
• Aannemen dat HTTPS of het hangslot dit al dekt. Versleuteling en anti-framing staan los van elkaar. Een perfect certificaat doet niets om uw pagina’s te beletten ingesloten te worden.
• Vertrouwen op oude noodgrepen. „Frame-busting”-JavaScript (scripts die uit frames proberen te breken) is onbetrouwbaar en kan worden omzeild. De headers zijn de juiste, browser-afgedwongen oplossing.

Veelgestelde vragen