Welches Problem der Header löst
Beim Clickjacking führt eine Oberfläche die Person über das tatsächliche Klickziel in die Irre. Eine fremde Seite kann beispielsweise ein erlaubtes eingebettetes Dokument transparent über einen sichtbaren Button legen. Der Klick landet dann auf dem darüberliegenden Frame. Ob daraus eine schädliche Aktion wird, hängt davon ab, ob die Anwendung die Aktion zulässt und die nötigen Anmeldedaten im Frame verfügbar sind.
Framing-Regeln setzen früher an: Sie verhindern die Anzeige in nicht erlaubten Einbettungskontexten. Das ist besonders für Kontoverwaltung, Administration und andere interaktive Dokumente relevant. Es ist kein Schutz vor sämtlicher Oberflächentäuschung, vor XSS oder vor unberechtigten Anfragen außerhalb des Browsers. Der heutige Verarbeitungsalgorithmus steht im HTML Living Standard, Abschnitt 7.7; der ältere RFC 7034 ist dafür nicht die allein maßgebliche Beschreibung.
Der Web Security Check wertet X-Frame-Options und die sichtbare CSP-Konfiguration der finalen Antwort nach Weiterleitungen aus. Er crawlt keine weiteren Seiten und probiert keine Einbettungen oder angemeldeten Aktionen. Ein fehlender Header auf einer JSON-Antwort hat daher eine andere Bedeutung als auf einem interaktiven Kontodokument.
Die Grenzen des Angriffsszenarios
Schematische Erklärung · keine Messung
Von der Einbettung zur möglichen Aktion
Schematische Erklärung · eine Aktion setzt passende Anmeldung, Berechtigungen und Anwendungslogik voraus.
- Fremde Seite bettet das Dokument ein
Der Browser prüft die Framing-Policy des eingebetteten Dokuments gegen die Vorfahrenkette.
Hier stoppt die Framing-Sperre: Ist die Einbettung unerlaubt, wird das Dokument nicht als Frame angezeigt.
- Person klickt auf die überlagerte Zieloberfläche
Nur bei gelungener Einbettung kann die Oberfläche dieser Variante über das tatsächliche Klickziel täuschen.
- Anwendung prüft die Aktion
Erst passende Anmeldedaten, Berechtigungen und Anwendungsregeln können eine Aktion ermöglichen. Eine zusätzliche Bestätigung kann sie begrenzen.
Eine unerlaubte Einbettung verhindern, bevor eine Interaktion möglich wird.
Der Ablauf besteht aus drei getrennten Schritten: Eine fremde Seite darf das Dokument zunächst einbetten. Die Person wird danach zu einem Klick auf dessen Oberfläche verleitet. Erst anschließend entscheidet die Anwendung, ob sie eine Aktion ausführt. Eine Framing-Sperre unterbricht bereits den ersten Schritt; eine zusätzliche Bestätigung kann den dritten begrenzen.
SameSite-Cookies ergänzen diesen Schutz, ersetzen ihn aber nicht. Werden Sitzungs-Cookies in einem Cross-Site-Frame zurückgehalten, kann eine angemeldete Aktion scheitern. Eine andere Origin derselben Site oder eine Anwendung mit anderem Authentifizierungsweg bleibt jedoch ein Gegenfall. Origin bedeutet Schema, Host und Port; Site fasst in diesem Zusammenhang Schema und registrierbare Domain zusammen. Details erläutert der Cookie-Ratgeber.
DENY, SAMEORIGIN oder eine Partner-Allowlist
Wählen Sie nach dem Einbettungsbedarf, nicht nach einer vermeintlich besseren Punktzahl.
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Gewünschtes Verhalten | Antwortheader beziehungsweise CSP-Direktive | Bedingung |
|---|---|---|
| Keine Einbettung | X-Frame-Options: DENY oder frame-ancestors 'none' | Auch eigene Einbettungen werden gesperrt. |
| Nur Einbettungen derselben Origin | X-Frame-Options: SAMEORIGIN oder frame-ancestors 'self' | Die gesamte Kette der übergeordneten Dokumente muss passen. |
| Eigene Origin und bestimmter Partner | frame-ancestors 'self' https://portal.example.net | Nur CSP bietet diese ausdrückliche Liste. Alle Vorfahren müssen zu einer erlaubten Origin gehören. |
https://example.com, https://shop.example.com und https://example.com:8443 sind unterschiedliche Origins. SAMEORIGIN bedeutet daher nicht „alle Unterdomains“. Ein Aufbau eigene Seite → fremder Zwischenframe → eigene Seite scheitert ebenfalls an der fremden Origin in der Vorfahrenkette. CSP3: frame-ancestors
Der ältere Wert ALLOW-FROM ist keine geeignete Partnerfreigabe. Der heutige HTML-Algorithmus behandelt ihn wie einen ungültigen Einzelwert; daraus entsteht keine belastbare Einbettungsbeschränkung. Auch mehrere widersprüchliche XFO-Werte sind keine Allowlist. Gleichlautende Doppelungen und widersprüchliche Werte werden unterschiedlich verarbeitet. Setzen Sie genau einen beabsichtigten Wert an einer zuständigen Stelle.
CSP und X-Frame-Options gemeinsam einsetzen
Diese Kombination passt zu Dokumenten, die überhaupt nicht eingebettet werden sollen:
Content-Security-Policy: frame-ancestors 'none'
X-Frame-Options: DENYDie CSP-Zeile ist nur der Framing-Ausschnitt. Ersetzen Sie damit keine vorhandene vollständige CSP; ergänzen beziehungsweise ändern Sie die Direktive in der zuständigen Policy. Mehrere durchgesetzte CSPs gelten gemeinsam und können eine Einbettung weiter einschränken.
Enthält die Antwort eine durchgesetzte frame-ancestors-Direktive, ignoriert ein unterstützender Browser XFO. Ein großzügiges frame-ancestors * wird daher nicht durch ein daneben stehendes DENY gerettet. Content-Security-Policy-Report-Only ersetzt XFO hingegen nicht. Ein XFO-Fallback muss auch für ältere Clients zum gewünschten Verhalten passen: SAMEORIGIN kann dort eine mit CSP erlaubte Partner-Einbettung blockieren. CSP3: Verhältnis zu XFO
frame-ancestors funktioniert nicht in einem CSP-Meta-Element. default-src 'none' ist kein Ersatz, weil frame-ancestors keinen solchen Fallback hat. frame-src beantwortet die umgekehrte Frage: Welche Frames darf die eigene Seite laden? Die übrige CSP-Konfiguration bleibt ein eigener Gegenstand.
Einführen, prüfen und zurücknehmen
- Erfassen Sie die relevanten Dokumente und gewollten Einbettungen: eigene Widgets, Partnerportale, Anmelde- und Zahlungswege. Prüfen Sie auch verschachtelte Frames.
- Legen Sie den Wert am tatsächlich zuständigen Webserver, Proxy, CDN oder in der Anwendung fest. Entfernen Sie dort widersprüchliche Doppelungen; pauschales Entfernen aller vorhandenen Schutzheader ist kein Rückweg.
- Kontrollieren Sie die ausgelieferte Antwort mit einem GET. Der folgende Beispielaufruf zeigt alle Headerblöcke der Weiterleitungskette; er wurde nicht gegen die Platzhalteradresse ausgeführt:
curl -sS -L -D - -o /dev/null https://www.example.com/konto/- Versuchen Sie im eigenen Testaufbau eine erlaubte und eine unerlaubte Einbettung. Prüfen Sie in der Browserkonsole, ob der Zielinhalt tatsächlich an der Framing-Policy scheitert. Ein leerer Frame kann auch durch Netzwerkfehler oder die
frame-src-Policy der Elternseite entstehen. - Testen Sie den benötigten Klickweg und die Fehlerseiten. CSP-Report-Only kann Hinweise liefern, ersetzt diesen Funktionstest aber nicht.
Für die Rücknahme stellen Sie die vorherige, dokumentierte Headerkonfiguration wieder her und laden ein neues Dokument. Bereits geladene Dokumente sowie zwischengespeicherte Antworten können den alten Stand behalten. Berücksichtigen Sie CDN- und Browsercache; der Ratgeber zu Implementierung und Architektur beschreibt die Zuständigkeiten im Auslieferungsweg.
Was sich damit nachweisen lässt
Dokumentierbar sind die gewollte Einbettungsregel, die tatsächlich ausgelieferte Antwort und das Verhalten der geprüften Browser und Nutzerwege. Daraus entsteht kein Nachweis umfassender NIS2-, Datenschutz- oder Zahlungskartenkonformität. Framing-Header erkennen auch keine Manipulationen von Zahlungsseiten und überwachen keine Headeränderungen. Die Compliance-Übersicht trennt technische Einzelmaßnahmen und weitergehende Anforderungen.
Häufig gestellte Fragen
Was ist Clickjacking?
Eine Oberfläche täuscht über das wirkliche Interaktionsziel. Bei der hier behandelten Variante liegt ein transparentes eingebettetes Dokument über sichtbaren Inhalten. Framing-Regeln verhindern ungewollte Einbettungen; eine erfolgreiche Aktion setzt zusätzlich passende Anmeldedaten und Anwendungslogik voraus.
Ist DENY besser als SAMEORIGIN?
DENY passt, wenn keine Einbettung erforderlich ist. SAMEORIGIN lässt eigene Einbettungen derselben Origin zu. Beide können richtig sein; ein notwendiger Nutzerweg darf nicht allein für eine strengere Einstellung ausfallen.
Ist X-Frame-Options veraltet?
Der Header bleibt im HTML-Standard definiert. CSP frame-ancestors bietet feinere Freigaben und hat als durchgesetzte Direktive Vorrang. Veraltet ist insbesondere die frühere Partnerfreigabe ALLOW-FROM.
Reichen SameSite-Cookies?
Sie können Cookie-basierte Aktionen in bestimmten Cross-Site-Frames begrenzen. Sie verhindern jedoch nicht jede Einbettung und erfassen nicht alle Authentifizierungs- oder Same-Site-Konstellationen. Framing-Regeln und Cookies haben unterschiedliche Aufgaben.
Warum blockiert der Browser meine eigene Einbettung?
Prüfen Sie zuerst den wirklichen Ziel-Origin nach Weiterleitungen, alle Vorfahren, beide Framing-Mechanismen und die frame-src-Policy der einbettenden Seite. Lockern Sie erst danach gezielt die Regel für den gewollten Weg. Eine Konsolenmeldung allein rechtfertigt keine allgemeine Freigabe.
Quellen und technischer Stand
- HTML Living Standard § 7.7
: aktuelle XFO-Verarbeitung, Mehrfachwerte, Vorfahren und CSP-Vorrang. - Content Security Policy Level 3 § 6.4.2
: Editor's Draft; Einbettungsregeln, Meta-Grenze und fehlender default-src-Fallback.
Quellenstand: 27.09.2026. Die genannten Einbettungsgegenfälle wurden lokal in Chromium 147.0.7727.15 geprüft. Keine Kundenanwendung, keine Browser-Vollmatrix und keine produktive Serverkonfiguration geprüft.