Clickjacking-Schutz: X-Frame-Options & frame-ancestors

Clickjacking-Angriffe nutzen unsichtbare iFrames, um Nutzer zu Klicks auf Ihrer Website zu verleiten. X-Frame-Options und CSP frame-ancestors verhindern die Einbettung Ihrer Seite in fremde Frames — in 5 Minuten konfiguriert.

Web Security · 10 Punkte
Web Security · Grundlagen

Warum Clickjacking-Schutz?

Clickjacking ist ein UI-Redress-Angriff, bei dem Ihre Website unsichtbar in einen fremden iFrame eingebettet wird — ein Klick des Nutzers löst dann unbemerkt Aktionen auf Ihrer Seite aus. Der Angreifer platziert Ihre Website in einem transparenten iFrame auf einer manipulierten Seite. Der Nutzer glaubt, auf einen harmlosen Button zu klicken — tatsächlich löst der Klick eine Überweisung, Passwortänderung oder Admin-Aktion auf Ihrer Website aus. Der Wolf-Agents Web Security Scanner prüft sowohl X-Frame-Options als auch CSP frame-ancestors und zeigt, ob Ihr Clickjacking-Schutz vollständig ist.

2010 kompromittierte der Facebook-Likejacking-Angriff Millionen Accounts durch unsichtbare Like-Buttons. 2009 verbreitete sich ein selbst-replizierender Clickjacking-Wurm über Twitter in wenigen Stunden auf tausende Accounts. Beide Angriffe wären durch einen einzigen HTTP-Header verhindert worden: X-Frame-Options.

Mio. Accounts durch Facebook Likejacking kompromittiert — unsichtbare Like-Buttons in fremden iFrames Facebook Likejacking 2010
5 Min. Implementierungszeit für X-Frame-Options — ein Header, der Clickjacking komplett verhindert Konfigurationsaufwand
A05 OWASP Top 10 — Security Misconfiguration: fehlende Security-Header sind die häufigste Ursache OWASP Top 10 2021
Angriffsszenario

Wie funktioniert Clickjacking?

Der Angreifer erstellt eine Seite mit einem sichtbaren Button ("Jetzt 1000 Euro gewinnen!") und platziert darüber einen unsichtbaren iFrame mit Ihrer Website. Der iFrame wird per CSS transparent gemacht (opacity: 0) und pixelgenau über dem sichtbaren Button positioniert. Das Opfer klickt auf den scheinbar harmlosen Button — der Klick geht durch den unsichtbaren iFrame direkt auf Ihre Website.

1
Angreifer bettet Ihre Seite ein

Die Angreifer-Website lädt Ihre Seite in einem unsichtbaren iFrame (opacity: 0). Der iFrame wird pixelgenau über einem sichtbaren Fake-Button positioniert.

2
Opfer klickt auf Fake-Button

Das Opfer sieht nur den sichtbaren Button ("Gewinnspiel"). Der Klick geht durch den transparenten iFrame direkt auf den echten Button Ihrer Website — z.B. "Überweisung bestätigen".

3
Ungewollte Aktion wird ausgeführt

Da das Opfer bei Ihrer Website eingeloggt ist (Session-Cookie aktiv), wird die Aktion authentifiziert ausgeführt: Geldtransfer, Passwortänderung, Admin-Rechte vergeben.

Konfiguration

DENY, SAMEORIGIN oder frame-ancestors?

X-Frame-Options kennt zwei gültige Werte: DENY blockiert jede iFrame-Einbettung, SAMEORIGIN erlaubt Einbettung nur von der eigenen Origin. Der veraltete Wert ALLOW-FROM funktioniert in keinem modernen Browser mehr. Für Multi-Origin-Allowlists verwenden Sie stattdessen CSP frame-ancestors.

Header / Direktive Wert Bedeutung
X-Frame-Options DENY Seite kann nirgends eingebettet werden
X-Frame-Options SAMEORIGIN Nur Einbettung von gleicher Origin erlaubt
frame-ancestors (CSP) 'none' Entspricht DENY — keine Einbettung erlaubt
frame-ancestors (CSP) 'self' Entspricht SAMEORIGIN — eigene Origin erlaubt
frame-ancestors (CSP) 'self' https://partner.de Multi-Origin-Allowlist — nur per CSP möglich
Empfehlung: Beide Header parallel setzen

Setzen Sie X-Frame-Options: SAMEORIGIN als Fallback für älteste Clients und frame-ancestors 'self' als primären Schutz. Bei Konflikten priorisieren moderne Browser frame-ancestors. Diese Defense-in-Depth-Strategie bietet maximale Kompatibilität.

Compliance

Clickjacking-Schutz und regulatorische Anforderungen

Clickjacking-Schutz ist eine technische Maßnahme, die mehrere regulatorische Anforderungen gleichzeitig erfüllt. Der Header ist ein dokumentierbarer Nachweis für Ihre TOM-Dokumentation (Technische und Organisatorische Maßnahmen).

NIS2 / §30 BSIG

Art. 21(2)(e) fordert Systemsicherheit bei Entwicklung und Wartung. Clickjacking-Schutz verhindert UI-Redress-Angriffe und ist ein prüfbarer Nachweis. Die Geschäftsleitung haftet persönlich nach §38 BSIG.

NIS2-Checkliste ansehen

PCI DSS 4.0.1

Req. 6.2.4 fordert Prevention gängiger Software-Angriffe. Req. 11.6.1 verlangt HTTP-Header-Monitoring. Clickjacking-Schutz via X-Frame-Options und frame-ancestors erfüllt beide Anforderungen direkt.

DSGVO Art. 32

Art. 32(1)(b) fordert Schutz der Integrität. Clickjacking-Schutz verhindert, dass Nutzer durch Täuschung zu unbeabsichtigten Aktionen verleitet werden — ein konkreter Nachweis für Ihre TOM-Dokumentation.

Wie steht Ihre Domain bei X-Frame-Options?

Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 166 Prüfpunkte.

Häufig gestellte Fragen

Was ist Clickjacking?

Clickjacking ist ein Angriff, bei dem eine bösartige Website Ihre Seite in einem unsichtbaren iFrame einbettet. Der Nutzer glaubt, auf der Angreiferseite zu klicken, interagiert aber tatsächlich mit Ihrer versteckten Seite — z.B. einer Banking-Überweisung oder einem Admin-Button.

Was ist der Unterschied zwischen X-Frame-Options und frame-ancestors?

X-Frame-Options ist der ältere HTTP-Header mit zwei Werten (DENY, SAMEORIGIN). CSP frame-ancestors ist der moderne Nachfolger und bietet zusätzlich Multi-Origin-Allowlists. Moderne Browser priorisieren frame-ancestors und ignorieren bei Konflikten X-Frame-Options. Best Practice: Beide Header parallel setzen.

DENY oder SAMEORIGIN — was ist besser?

DENY blockiert jede iFrame-Einbettung — auch von der eigenen Domain. SAMEORIGIN erlaubt Einbettung von der gleichen Origin. Verwenden Sie DENY, wenn Ihre Website keine iFrame-Einbettung benötigt (Standard für die meisten Websites). Verwenden Sie SAMEORIGIN nur, wenn Sie Ihre eigenen Seiten in iFrames einbetten (z.B. Dashboard-Widgets).

Ist X-Frame-Options deprecated?

Ja, X-Frame-Options ist laut MDN offiziell deprecated. Der Nachfolger ist die CSP-Direktive frame-ancestors. Trotzdem sollten Sie X-Frame-Options weiterhin als Fallback setzen — älteste Clients und einige WebViews unterstützen nur X-Frame-Options. Defense-in-Depth: Beide Header parallel setzen schadet nicht.

Brauche ich den Header, wenn ich SameSite-Cookies nutze?

Ja. SameSite-Cookies (Lax/Strict) verhindern nur authentifizierte Clickjacking-Angriffe — die Session wird in Cross-Site-iFrames nicht gesendet. Aber unauthentifizierte Clickjacking bleibt möglich (z.B. Like-Buttons, Share-Buttons). X-Frame-Options und frame-ancestors bleiben die primäre Verteidigung.

Warum zeigt mein Browser "Refused to display in a frame"?

Diese Meldung erscheint, wenn X-Frame-Options oder frame-ancestors die iFrame-Einbettung blockiert. Wenn Ihre eigene Seite nicht in einem eigenen iFrame angezeigt wird, wechseln Sie von DENY zu SAMEORIGIN (bzw. frame-ancestors 'self'). Prüfen Sie auch, ob der Header auf allen Seiten konsistent gesetzt ist.