X-Frame-Options im Detail: Schutz vor Clickjacking-Angriffen

Der HTTP-Response-Header X-Frame-Options ist eine bewährte Sicherheitsanweisung, die das Einbetten der eigenen Website in iframes, Frames oder Objects auf anderen Websites regelt. Er dient primär als Schutzmassnahme gegen Clickjacking-Angriffe (UI-Redressing). Durch die Einschränkung der Frame-Fähigkeit wird sichergestellt, dass Angreifer Ihre Benutzeroberfläche nicht manipulieren können, um Aktionen im Namen Ihrer Nutzer auszuführen.

X-Frame-Options ist Teil eines Verbunds von Security-Headern, der jede Website gegen typische Angriffe absichert. Während die Content-Security-Policy Code-Injektion verhindert, deckt X-Frame-Options gezielt das Einbetten in fremde Seiten ab – zwei unterschiedliche, sich ergänzende Schutzziele.

Das Prinzip von Clickjacking

Bei einem Clickjacking-Angriff nutzt der Angreifer das Standardverhalten von Webbrowsern aus, beliebige Webseiten per iframe einbetten zu können:

1. Der Angreifer baut eine scheinbar harmlose Website auf (z. B. „Klicken Sie hier, um ein Geschenk zu erhalten“).
2. Er bettet die Ziel-Website (z. B. die Einstellungs-Seite Ihres Portals) in einem iframe auf seiner Seite ein.
3. Per CSS setzt er die Deckkraft (Opacity) des iframes auf 0 (vollständig transparent).
4. Er positioniert den unsichtbaren iframe so, dass der kritische Button der Zielseite (z. B. „Konto löschen“) exakt über dem auffälligen Button seiner eigenen Seite („Geschenk abholen“) liegt.
5. Klickt der Benutzer auf den Geschenk-Button, klickt er in Wirklichkeit auf den unsichtbaren Löschen-Button. Da der Browser die Cookies des Nutzers automatisch mitsendet, wird die Aktion erfolgreich ausgeführt.

---

Die Konfigurationswerte von X-Frame-Options

Der Header unterstützt zwei primäre Direktiven (eine dritte ist veraltet):

1. X-Frame-Options: DENY

Verbietet das Einbetten der Website in iframes komplett – unabhängig davon, wer den Versuch unternimmt. Selbst die eigene Website darf die Seite nicht in einem iframe anzeigen. Dies ist die sicherste Einstellung und wird für fast alle normalen Informationsseiten empfohlen.

2. X-Frame-Options: SAMEORIGIN

Erlaubt das Einbetten in iframes ausschliesslich für Seiten, die auf derselben Domain (Origin) laufen. Dies ist nützlich, wenn Sie innerhalb Ihres Portals mit internen iframes arbeiten müssen.

3. ALLOW-FROM uri (Veraltet)

Sollte historisch das Einbetten nur für eine spezifische Domain erlauben. Dieser Eintrag ist veraltet und wird von fast allen modernen Browsern ignoriert.

---

Der moderne Nachfolger: CSP frame-ancestors

Die Funktionalität von X-Frame-Options wurde im modernen Web-Standard in die Content Security Policy (CSP) integriert. Die Direktive frame-ancestors bietet eine deutlich höhere Flexibilität:

• CSP-Beispiel: Content-Security-Policy: frame-ancestors 'self' https://partner-site.com;
• Dies erlaubt das Einbetten für die eigene Domain und explizit für die Partnerseite, was mit X-Frame-Options unmöglich war.
• Browserverhalten: Unterstützt ein Browser beide Header, ignoriert er laut Spezifikation X-Frame-Options und wendet ausschliesslich die strengeren Regeln der CSP frame-ancestors an.

---

X-Frame-Options vs. CSP frame-ancestors im Vergleich

Beide Mechanismen schützen vor Clickjacking, unterscheiden sich aber in Flexibilität und Browser-Unterstützung:

Kriterium	X-Frame-Options	CSP frame-ancestors
Mehrere erlaubte Domains	Nein	Ja (Liste möglich)
Wildcards / Subdomains	Nein	Ja
Status	Legacy, aber breit unterstützt	Moderner Standard
Ältere Browser	Ja	Teilweise nicht
Vorrang bei Konflikt	Wird ignoriert	Gilt

Empfehlung: Beide gemeinsam setzen – frame-ancestors als primäre Regel, X-Frame-Options als Fallback. Wie sich solche Regeln sauber in eine Gesamtrichtlinie einfügen, zeigt der Artikel zu den CSP Best Practices.

---

Typische Fehlkonfigurationen

In der Praxis scheitert der Clickjacking-Schutz oft an wenigen, wiederkehrenden Fehlern:

Fehler	Folge	Korrektur
Header nur auf der Startseite gesetzt	Unterseiten bleiben angreifbar	Header serverweit (global) setzen
ALLOW-FROM als alleinige Regel	Wird von Browsern ignoriert	frame-ancestors nutzen
Header im HTML <meta>-Tag	X-Frame-Options wirkt nur als HTTP-Header	Über Serverkonfiguration ausliefern
Mehrere widersprüchliche Werte	Browser verwirft den Header	Genau einen Wert definieren

Besonders der dritte Punkt ist tückisch: Anders als die CSP lässt sich X-Frame-Options nicht über ein <meta http-equiv>-Tag setzen, sondern ausschliesslich als echter HTTP-Antwortheader.

---

Praxisbeispiel: korrekte Konfiguration

Für eine typische Informations- oder Login-Seite, die nirgends eingebettet werden soll, sieht die robuste Doppelabsicherung so aus:

X-Frame-Options: DENY
Content-Security-Policy: frame-ancestors 'none';

Muss eine Seite hingegen innerhalb des eigenen Portals als iframe laufen, lautet die Kombination:

X-Frame-Options: SAMEORIGIN
Content-Security-Policy: frame-ancestors 'self';

Nach dem Setzen sollten Sie prüfen, ob der Header tatsächlich auf allen URLs ausgeliefert wird – ein häufiger Fehler ist, dass nur die Startseite, nicht aber tiefere Seiten geschützt sind.

[!TIP] Die Deaktivierung der Frame-Fähigkeit für sensible Login- oder Transaktionsseiten ist eine absolute Pflicht-Massnahme für Webmaster. Prüfen Sie, ob Ihre Website gegen Clickjacking geschützt ist, mit dem Security Header Check auf balou.tools.