X-Frame-Options: Was der Header macht und wie Sie ihn richtig setzen

X-Frame-Options ist ein HTTP-Response-Header, der dem Browser mitteilt, ob Ihre Seite innerhalb eines Frames oder iframes auf einer anderen Website dargestellt werden darf. Er kennt genau zwei gültige Werte: DENY (keinerlei Einbettung) und SAMEORIGIN (Einbettung nur von der eigenen Origin). Sein Zweck ist es, Clickjacking zu verhindern, einen Angriff, bei dem Ihre Website unsichtbar in die Seite eines Angreifers geladen wird und Besucher dazu gebracht werden, auf Dinge zu klicken, die sie nicht sehen. Der moderne Nachfolger ist die Content-Security-Policy-Direktive frame-ancestors, und Best Practice 2026 ist, beide Header zu senden. Dieser Leitfaden zeigt die korrekte Konfiguration für alle gängigen Server sowie die Fehler, die den Schutz stillschweigend abschalten.

Was der X-Frame-Options-Header bewirkt

Wenn ein Browser eine Seite lädt, die ein anderes Dokument per <iframe>, <frame>, <embed> oder <object> eingebettet hat, prüft er vor dem Rendern die Response-Header der eingebetteten Seite. Enthält die Antwort X-Frame-Options: DENY, weigert sich der Browser, die Seite innerhalb des einbettenden Dokuments darzustellen. Bei SAMEORIGIN wird die Seite nur gerendert, wenn die gesamte Einbettungskette von derselben Origin stammt (gleiches Schema, gleicher Host, gleicher Port). Moderne Browser prüfen die komplette Kette der übergeordneten Frames, nicht nur das oberste Fenster.

Formalisiert wurde der Header im Oktober 2013 in RFC 7034, nachdem die Browser ihn längst eingeführt hatten. Er gehört weiterhin zu den am weitesten verbreiteten Security-Headern: Das Sicherheitskapitel des HTTP Archive Web Almanac 2025 misst X-Frame-Options auf rund 35 % der mobilen Websites, womit er hinter X-Content-Type-Options (knapp 50 %) zu den drei häufigsten Security-Headern zählt.

Clickjacking in 60 Sekunden

Der Begriff Clickjacking wurde 2008 von den Sicherheitsforschern Robert Hansen und Jeremiah Grossman geprägt. Der Angriff ist simpel: Die Seite des Angreifers lädt Ihre Website in ein iframe, macht es per CSS vollständig transparent und positioniert es über harmlos aussehenden Buttons. Der Besucher glaubt, auf "Video abspielen" zu klicken, doch der Klick landet tatsächlich auf "Konto löschen", "Zahlung bestätigen" oder "App autorisieren" Ihrer Website, mit der eingeloggten Session des Opfers. OWASP dokumentiert Varianten vom Facebook-"Likejacking" bis zu gekaperten Ein-Klick-Käufen.

Die Verteidigung ist Einbettungskontrolle. Weigert sich der Browser, Ihre Seite im Frame des Angreifers zu rendern, bricht der Überlagerungstrick zusammen.

Die zwei gültigen Werte, und die, die Sie meiden sollten

Das Gefährliche ist der Umgang der Browser mit ungültigen Werten: Sie ignorieren den kompletten Header. Eine Website, die ALLOW-FROM oder ALLOWALL sendet, wähnt sich geschützt, während Browser sie behandeln, als wäre gar kein Header gesetzt. Der Web Almanac 2025 formuliert es so: Diese Werte wurden vermutlich von Entwicklern gesetzt, die davon ausgingen, dass der Schutz aktiv sei, weil der Header vorhanden ist.

Was die realen Daten zeigen

Über die Millionen von Websites, die HTTP Archive 2025 vermessen hat, verteilen sich die Header-Werte so:

Quelle: HTTP Archive Web Almanac 2025, Sicherheitskapitel, Abbildung 9.30 (mobile Daten).

Rund 72,1 % der Websites, die den Header senden, wählen SAMEORIGIN, 24,6 % wählen DENY. Etwa 3 % senden Werte ohne jede Wirkung, was auf die Größe des Webs gerechnet Hunderttausende Websites mit eingebildetem Schutz bedeutet. Zu prüfen, was Ihr Server tatsächlich sendet, dauert keine Minute.

X-Frame-Options vs. CSP frame-ancestors

Die W3C-Spezifikation Content Security Policy Level 2 (seit Dezember 2016 W3C Recommendation) führte die Direktive frame-ancestors ein und erklärte X-Frame-Options formell für obsolet. Wo XFO ein grober Ein-Aus-Schalter ist, ist frame-ancestors eine vollwertige Positivliste:

Zwei Details lohnen sich zu wissen. Erstens weist MDN darauf hin, dass frame-ancestors nicht von default-src erbt: Eine Policy default-src 'none' erlaubt weiterhin jedem, die Seite einzubetten, die Direktive muss also explizit deklariert werden. Zweitens unterstützen alle aktuellen Versionen von Chrome, Edge, Firefox und Safari frame-ancestors, der einzige Grund, X-Frame-Options weiter zu senden, ist Defense in Depth für sehr alte Clients. Das kostet eine Zeile, also behalten Sie sie.

So konfigurieren Sie den Header auf Ihrem Server

Senden Sie den Header mit jeder HTML-Antwort, genau einmal. Die folgenden Beispiele setzen SAMEORIGIN plus die entsprechende CSP-Direktive.

nginx (innerhalb von server oder location):

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

Apache 2.4 (httpd.conf oder .htaccess, mod_headers aktiviert):

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

IIS (web.config):

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

Node.js mit Express und Helmet:

const helmet = require("helmet");
app.use(helmet.frameguard({ action: "sameorigin" }));
app.use(helmet.contentSecurityPolicy({
  directives: { frameAncestors: ["'self'"] }
}));

Hinter einem CDN wie Cloudflare können Sie beide Header auch über eine Response-Header-Transformationsregel injizieren, praktisch, wenn Sie den Origin-Server nicht anfassen können. Muss ein Partner Ihre Seite legitim einbetten, lassen Sie XFO auf SAMEORIGIN und drücken die Positivliste in CSP aus: frame-ancestors 'self' https://partner.beispiel.de.

Fehler, die den Schutz stillschweigend abschalten

• ALLOW-FROM im Jahr 2026 verwenden. Jeder aktuelle Browser ignoriert es, und damit den gesamten Header.
• Den Header in einem Meta-Tag setzen. X-Frame-Options funktioniert nur als echter HTTP-Header, und frame-ancestors ist in <meta http-equiv="Content-Security-Policy"> ausdrücklich verboten. Beide müssen vom Server kommen.
• Den Header doppelt senden. Doppelte oder kommagetrennte Werte wie SAMEORIGIN, SAMEORIGIN (0,28 % der Websites im Almanac 2025) können als ungültig verworfen werden. Setzen Sie ihn an genau einer Stelle, entweder in der Anwendung oder im Webserver, nicht in beiden.
• DENY auf Seiten verwenden, die Sie selbst einbetten. Läuft Ihr eigener Checkout, ein Widget oder eine Vorschau in einem iframe, macht DENY sie kaputt. Verwenden Sie SAMEORIGIN oder eine explizite frame-ancestors-Liste.
• Annehmen, dass default-src die Einbettung abdeckt. Tut es nicht. Deklarieren Sie frame-ancestors explizit.

So testen Sie Ihre Konfiguration

Öffnen Sie die Entwicklertools des Browsers, laden Sie Ihre Seite und prüfen Sie die Response-Header des Hauptdokuments: Sie sollten genau einen X-Frame-Options-Header und eine Content-Security-Policy mit frame-ancestors sehen. Für das Gesamtbild prüft der kostenlose FortifyNet-Scan Ihren Einbettungsschutz zusammen mit dem Rest Ihrer Security-Header, SSL/TLS, DNS und E-Mail-Authentifizierung in rund 60 Sekunden und sagt Ihnen genau, welchen Header Sie wo ergänzen müssen. Ohne Registrierung.

Verwandte Leitfäden

• HTTP-Sicherheits-Header: der vollständige Leitfaden
• Was ist HSTS? HTTP Strict Transport Security erklärt
• Website-Sicherheits-Checkliste: 12 wichtige Schritte

Häufige Fragen

Ist X-Frame-Options veraltet? Formal ja: W3C CSP Level 2 hat ihn bereits 2016 zugunsten von frame-ancestors für obsolet erklärt. In der Praxis respektiert ihn weiterhin jeder Browser, und OWASP empfiehlt, beide Header als Defense in Depth zu senden. Was Sie keinesfalls tun dürfen, ist sich auf ALLOW-FROM zu verlassen.

Soll ich DENY oder SAMEORIGIN verwenden? Verwenden Sie DENY, wenn nichts auf Ihrer Website jemals in einem Frame angezeigt wird, das ist die stärkste Einstellung. Verwenden Sie SAMEORIGIN, wenn Ihre eigenen Seiten einander einbetten, etwa Dashboards, Vorschauen oder interne Widgets. In den Daten des Web Almanac 2025 wählen 72,1 % der Websites SAMEORIGIN.

Wie erlaube ich einer bestimmten Partner-Website, meine Seiten einzubetten? X-Frame-Options kann das nicht mehr. Verwenden Sie Content-Security-Policy: frame-ancestors 'self' https://partner.beispiel.de und listen Sie jede erlaubte Origin explizit auf.

Was passiert, wenn ich X-Frame-Options und frame-ancestors gleichzeitig sende? Browser mit CSP-Level-2-Unterstützung, also alle modernen, setzen frame-ancestors durch und ignorieren X-Frame-Options. Ältere Clients greifen auf X-Frame-Options zurück. Genau diese Rückfallkette ist der Grund, warum beide empfohlen werden.

Kann ich X-Frame-Options per Meta-Tag setzen? Nein. Browser respektieren ihn nur als echten HTTP-Response-Header. Wenn Sie die Serverkonfiguration nicht ändern können, setzen Sie ihn über das Hosting-Panel, CDN-Regeln oder die Middleware Ihrer Anwendung.