Defaults.Exposed › Behebungen › Clickjacking-Schutz (X-Frame-Options)

So beheben Sie Clickjacking-Schutz (X-Frame-Options)

Eine einzeilige Anweisung, die Browsern verbietet, Ihre Website heimlich innerhalb fremder Websites zu laden. Ohne sie kann ein Betrüger Ihre echten, eingeloggten Seiten hinter einer gefälschten Seite verstecken und Ihre Kunden dazu verleiten, Dinge anzuklicken, die sie nie wollten — eine Zahlung freizugeben, ein Passwort zu ändern, einen Zugriff zu gewähren.

Das Wichtigste für Ihr Unternehmen: Ein Betrüger kann Ihre echte Website unsichtbar in eine gefälschte einbetten und Ihren eingeloggten Kunden Geld oder Kontozugang stehlen — und für den Kunden sieht es so aus, als hätte Ihre Seite das verursacht. Die Behebung ist kostenlos und dauert für eine Entwicklerin rund 15 Minuten; sie wegzulassen ist eine bekannte Lücke, die sowohl Kriminelle als auch vorsichtige Käufer in Sekunden erkennen.

Was Sie das kosten kann

• Ein Betrüger versteckt Ihren echten Login- oder Zahlungsbildschirm hinter einer harmlos wirkenden Seite und verleitet einen Kunden dazu, eine Überweisung oder Einstellungsänderung zu 'bestätigen', ohne es zu merken — der Kunde gibt Ihnen die Schuld, nicht dem Angreifer.
• Ihr eingeloggter Kontobereich wird unsichtbar über eine 'Sie haben gewonnen — jetzt einlösen'-Seite gelegt; der Klick genehmigt in Wahrheit eine echte Änderung am Konto des Kunden, und Sie nehmen den verärgerten Support-Anruf entgegen.
• Das IT-Team eines Interessenten führt vor Vertragsabschluss einen schnellen Sicherheits-Scan durch, sieht, dass Ihre Seite von jedem eingebettet werden kann, und markiert das als Risiko, das den Abschluss verzögert oder kippt.
• Ihre Marke wird zum Köder in einer Betrugskampagne; Kunden, die hereinfallen, erinnern sich an Sie als 'das Unternehmen, dessen Seite das zugelassen hat'.
• Ein Prüfer oder ein Cyber-Versicherungs-Scan listet fehlenden Clickjacking-Schutz als Versagen bei der Grundhygiene auf — billig zu beheben, peinlich, wenn es bemängelt wird.

Warum es wichtig ist. Dies ist eine kostenlose, einzeilige Einstellung, die in Minuten hinzugefügt ist und eine ganze Klasse von Tricks gegen Ihre eingeloggten Kunden unterbindet. In unserer Bewertung ist dies eine punktrelevante Web-Sicherheitsprüfung mit hoher Schwere, denn ein fehlender Header hinterlässt eine bekannte, leicht prüfbare Lücke, die Kriminelle automatisieren und Käufer gezielt suchen.

Worum es geht, in einfachen Worten

Wenn jemand Ihre Website besucht, kann seinem Browser auch gesagt werden, Ihre Website innerhalb einer anderen Website zu laden — wie ein kleines Fenster, eingebettet in eine größere Seite. Das klingt harmlos, und manchmal ist es das auch. Aber es ist der Mechanismus hinter einem Angriff namens Clickjacking.

So funktioniert der Trick. Ein Betrüger baut seine eigene Seite und lädt Ihre echte Website still und heimlich hinein — unsichtbar, vollständig transparent gemacht. Dann legt er seine eigenen Inhalte darüber: einen auffälligen Button, ein “Video abspielen”, ein “Prämie einlösen”. Ihr Kunde sieht die Seite des Angreifers und klickt auf etwas, das wie ein harmloser Button aussieht. Aber weil Ihre echte Seite unsichtbar unter dem Mauszeiger liegt, landet der Klick in Wahrheit auf Ihrer Seite — bestätigt eine Zahlung, ändert ein Passwort, genehmigt einen Zugriff, akzeptiert eine Berechtigung. Der Kunde denkt, er hätte das eine geklickt; tatsächlich hat er etwas anderes geklickt, auf einer Seite, der er vertraut.

Clickjacking-Schutz ist eine kurze, unsichtbare Anweisung, die Ihre Website an den Browser jedes Besuchers sendet und im Grunde sagt:

“Lass keine fremden Websites mich in sich laden. Wenn jemand es versucht, verweigere es.”

Moderne Browser befolgen das automatisch. Ist er eingeschaltet, funktioniert der Trick schlicht nicht — die eingebettete Kopie Ihrer Seite verweigert das Laden. Ohne ihn ist Ihre Seite Freiwild, um als versteckte Ebene in einem Betrug benutzt zu werden, und der hereingelegte Kunde verbindet das Ganze mit Ihrer Marke, nicht mit der des Angreifers.

Was Sie das kosten kann

Dies sind realistische, alltägliche Szenarien. Wir nennen nie ein echtes Unternehmen; das sind Veranschaulichungen, wie die Lücke ausgenutzt wird.

1. Das unsichtbare “Bestätigen”. Ein Kunde ist in einem Tab in Ihrem Kontoportal eingeloggt. Er landet auf einer Seite (aus einer Anzeige, einer E-Mail, einem Suchergebnis), die etwas Verlockendes verspricht und einen großen “Weiter”-Button zeigt. Versteckt darunter liegt Ihr echtes “Überweisung bestätigen”- oder “E-Mail ändern”-Element, geladen aus seiner eigenen eingeloggten Sitzung. Er klickt “Weiter” — und genehmigt unwissentlich eine Änderung an seinem tatsächlichen Konto bei Ihnen. Für ihn und für Ihr Support-Team sieht es so aus, als hätte er das auf Ihrer Seite getan.

2. Die Einstellungs-Entführung. Ein Angreifer rahmt Ihre Kontoeinstellungsseite ein und legt ein harmloses Spiel oder eine Umfrage darüber. Ein paar Klicks an den richtigen Stellen kippen still eine Einstellung um — fügen die E-Mail des Angreifers als Wiederherstellungsadresse hinzu, gewähren einer App eine Berechtigung oder deaktivieren eine Sicherheitswarnung. Das Konto ist nun heimlich kompromittiert, und nichts sah in dem Moment falsch aus.

3. Der ins Stocken geratene Abschluss. Ein größerer Kunde schickt vor Vertragsabschluss seinen Standard-Sicherheitsfragebogen. Eine Zeile fragt, ob Ihre Seite Anti-Framing-Schutz setzt (X-Frame-Options / CSP frame-ancestors). Ihr IT-Kontakt muss “nein” antworten, und der Einkauf pausiert, während Sie hektisch eine kostenlose 15-Minuten-Einstellung nachholen, die nun vor einem Käufer wie eine Warnflagge wirkt.

4. Die Marke-als-Köder-Kampagne. Weil Ihre echten, vertrauenswürdigen Seiten eingebettet werden können, nutzt ein Angreifer Ihren Login oder Checkout als überzeugende Ebene in einer breiteren Phishing-Kampagne. Die hereingelegten Kunden geben nicht dem schattenhaften Angreifer die Schuld — sie erinnern sich an die Zeit, als “Ihre Seite” sie betrügen ließ.

5. Die Prüf-Markierung. Der Scan eines Versicherers oder ein Prüfer Ihrer Sicherheitslage listet fehlenden Clickjacking-Schutz unter den Befunden auf. Es ist ein Lehrbuch-Punkt der Grundhygiene; ihn bemängelt zu bekommen signalisiert, dass die einfachen, kostenlosen Schutzmaßnahmen nicht vorhanden waren — was die Beurteilung Ihrer übrigen Sicherheit färbt.

Der rote Faden: der Schaden trifft einen echten, eingeloggten Kunden, der etwas tut, das er nicht beabsichtigt hat — und er trägt Ihren Namen, nicht den des Angreifers.

Was es tatsächlich ist

Wenn ein Browser Ihre Website um eine Seite bittet, sendet Ihr Server die Seite zurück plus einige unsichtbare “Header” — zusätzliche Anweisungen, die der Browser liest, der Besucher aber nie sieht. Clickjacking-Schutz wird über diese Header ausgeliefert. Es gibt zwei, und unsere Prüfung besteht, wenn einer vorhanden ist:

1. Der ältere Header — X-Frame-Options:

X-Frame-Options: SAMEORIGIN

Dies ist die langjährige, breit unterstützte Kontrolle. Sie nimmt einen von zwei praktischen Werten an:

• SAMEORIGIN — Ihre eigene Seite darf ihre eigenen Seiten einbetten, keine fremde Seite jedoch. Der sichere Standard für fast jeden.
• DENY — niemand darf Ihre Seiten einbetten, auch Sie nicht. Nur verwenden, wenn Ihre Seite ihre eigenen Inhalte nie einrahmt.

2. Der moderne Header — Content-Security-Policy frame-ancestors:

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

Dies ist die neuere, flexiblere Kontrolle und jene, auf die aktuelle Standards verweisen. Sie leistet dasselbe, erlaubt Ihnen aber, genau festzulegen, wer Sie einbetten darf:

• frame-ancestors 'self' — entspricht SAMEORIGIN.
• frame-ancestors 'none' — entspricht DENY.
• frame-ancestors 'self' https://partner.example.com — Ihre eigene Seite plus ein benannter, vertrauenswürdiger Partner, und sonst niemand.

Wie “gut” aussieht

Der stärkste Aufbau nutzt beide: frame-ancestors für moderne Browser (und für die Präzision, erlaubte Einbetter zu benennen) und X-Frame-Options: SAMEORIGIN als Rückfallebene für ältere Clients. Unsere Prüfung ist mit einem von beiden allein erfüllt — aber da beide kostenlos sind und dieselben paar Minuten brauchen, gibt es keinen Grund, nicht beide zu setzen.

Ein wichtiges Detail, das Ihre Entwicklerin kennen sollte: ein Content-Security-Policy-Report-Only-Header erzwingt nichts — er meldet nur. Soll der Clickjacking-Schutz tatsächlich wirken, muss er von einem erzwingenden Header kommen (einer normalen Content-Security-Policy mit frame-ancestors oder X-Frame-Options), nicht von einem Nur-Bericht-Header.

So beheben Sie es (kostenlos, ~15 Minuten)

Geben Sie diesen Abschnitt an die Person weiter, die Ihre Website betreut — Ihre IT-Kraft, Webentwicklerin oder Ihren Hosting-Support. Die Behebung ist kostenlos. Es sind ein oder zwei Antwort-Header oder eine Regel in Ihrem CDN. Es gibt nichts zu kaufen.

Die Prüfung besteht, wenn entweder ein X-Frame-Options-Header (auf DENY oder SAMEORIGIN) oder eine CSP-frame-ancestors-Direktive vorhanden ist. Der empfohlene doppelt abgesicherte Aufbau fügt beide hinzu.

Schritt 1 — Entscheiden, wie streng

• Die meisten Unternehmen: SAMEORIGIN / frame-ancestors 'self'. Ihre eigene Seite funktioniert weiter; Außenstehende werden blockiert.
• Wenn Ihre Seite ihre eigenen Seiten nie einbettet: DENY / frame-ancestors 'none' für maximale Abriegelung.
• Wenn ein echter Partner eine bestimmte Seite einbetten muss: benennen Sie ihn ausdrücklich mit frame-ancestors 'self' https://partner.example.com; — und niemand sonst kommt herein.

Schritt 2 — Die Header hinzufügen (Ihre Plattform wählen)

Nginx — innerhalb Ihres server-Blocks:

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

Apache — stellen Sie sicher, dass mod_headers aktiviert ist, dann in Ihrem Virtual Host:

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

Microsoft IIS — in web.config innerhalb von <customHeaders>:

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

Cloudflare (oder ein ähnliches CDN): gehen Sie zu Rules → Transform Rules → Modify Response Header und fügen Sie zwei Regeln hinzu, die X-Frame-Options auf SAMEORIGIN und Content-Security-Policy auf frame-ancestors 'self'; für alle Antworten setzen. Das ist der einfachste Weg, wenn Sie keinen direkten Serverzugriff haben.

Senden Sie bereits aus anderen Gründen eine Content-Security-Policy? Erstellen Sie keinen zweiten CSP-Header — fügen Sie frame-ancestors in Ihre bestehende Richtlinie ein. Zwei CSP-Header können in Konflikt geraten.

Website-Baukästen (Squarespace, Wix, Shopify und ähnliche): diese Plattformen setzen Anti-Framing-Schutz oft für Sie, sodass Sie womöglich bereits bestehen, ohne etwas tun zu müssen. Markiert unsere Prüfung es, liegt die Kontrolle meist in den Sicherheitseinstellungen der Plattform, oder Sie ergänzen sie im CDN, das der Seite vorgelagert ist. (Hinweis: Google Workspace und Microsoft 365 betreiben Ihre E-Mail, nicht Ihre Website — dieser Header wird dort gesetzt, wo Ihre öffentliche Seite tatsächlich liegt, nicht in der Workspace-/365-Verwaltung.)

Schritt 3 — Neu laden und prüfen

Laden Sie den Webserver neu oder rollen Sie die CDN-Regel aus, rufen Sie dann Ihre Live-Seite auf und prüfen Sie die Antwort-Header — Browser-Entwicklertools → Tab Netzwerk → Klick auf die Seitenanfrage → Response Headers, oder ein beliebiges kostenloses Header-Prüfwerkzeug. Bestätigen Sie, dass der/die Header bei echten Seitenantworten erscheinen, nicht nur auf der Startseite. Führen Sie dann die Prüfung erneut aus.

Häufige Fehler

• Eine Nur-Bericht-CSP verwenden und annehmen, sie schütze Sie. Content-Security-Policy-Report-Only meldet nur Verstöße — sie erzwingt nichts. Damit der Schutz wirkt, brauchen Sie einen erzwingenden Header.
• Zwei getrennte Content-Security-Policy-Header setzen. Haben Sie bereits eine CSP, fügen Sie frame-ancestors darin ein, statt eine zweite Richtlinie auszugeben; widersprüchliche CSP-Header können unerwartetes Verhalten erzeugen.
• DENY setzen, obwohl Ihre eigene Seite ihre eigenen Seiten einbettet. DENY blockiert jedes Framing, auch Ihr eigenes. Wenn irgendein Teil Ihrer Seite iframes von sich selbst nutzt, verwenden Sie stattdessen SAMEORIGIN / frame-ancestors 'self', sonst zerbrechen Sie Ihre eigenen Seiten.
• Nur die Startseite schützen. Die für Clickjacking wichtigsten Seiten sind die eingeloggten — Kontoeinstellungen, Zahlungsbestätigung, Administration. Stellen Sie sicher, dass die Header seitenweit gelten, nicht nur auf der Frontseite.
• Annehmen, HTTPS oder das Schloss decke das bereits ab. Verschlüsselung und Anti-Framing sind unverbunden. Ein perfektes Zertifikat tut nichts, um das Einbetten Ihrer Seiten zu verhindern.
• Sich auf alte Behelfslösungen verlassen. “Frame-Busting”-JavaScript (Skripte, die aus Frames ausbrechen wollen) ist unzuverlässig und umgehbar. Die Header sind die korrekte, vom Browser erzwungene Behebung.

FAQ