Clickjacking verhindern: X-Frame-Options und frame-ancestors

Warum das wichtig ist

Der Trick funktioniert so: Eine präparierte Seite zeigt etwas Harmloses, zum Beispiel ein Gewinnspiel mit einem großen Knopf. Darüber liegt, auf durchsichtig gestellt, deine Seite im iframe. Wer auf „Jetzt teilnehmen“ klickt, klickt in Wahrheit auf einen Knopf deiner Seite, etwa „Bestellung absenden“ oder eine Einstellung im Kundenkonto.

Gefährlich wird das vor allem, wenn deine Seite Aktionen mit einem Klick erlaubt und Besucher dabei eingeloggt sind: Shops, Kundenportale, Mitgliederbereiche, das WordPress-Backend. Eine reine Visitenkarten-Website ohne Login hat wenig zu verlieren. Der Schutz kostet trotzdem nur eine Zeile, und du musst nicht bei jeder neuen Funktion überlegen, ob sie ihn brauchen würde.

Nebenbei verhindert der Header, dass jemand deine Seite komplett in seine eigene einbettet und als seinen Inhalt ausgibt.

So prüfst du es selbst

Schau in den Antwort-Headern deiner Startseite nach x-frame-options oder nach frame-ancestors innerhalb von content-security-policy:

curl -sI https://example.de | grep -iE "x-frame-options|content-security-policy"

Was checkfrei prüft

checkfrei sucht beides. Ist eins davon als HTTP-Header gesetzt, ist der Punkt erfüllt. Fehlt beides, gibt es eine Warnung. Den Stand deiner Seite siehst du im kostenlosen Check.

So behebst du es

Für die meisten Websites ist SAMEORIGIN richtig: Deine eigene Seite darf sich selbst einbetten, was etwa die Vorschau im WordPress-Customizer braucht, fremde Seiten dürfen es nicht. DENY verbietet jede Einbettung, auch die eigene.

X-Frame-Options gilt offiziell als veraltet. Der Nachfolger ist frame-ancestors in der Content-Security-Policy, der auch mehrere erlaubte Domains kennt. Unterstützt wird X-Frame-Options aber weiterhin überall. In der Praxis setzen wir beides: Browser, die frame-ancestors kennen, ignorieren dann X-Frame-Options, ältere nehmen den alten Header.

Wichtig: Beides funktioniert nur als echter HTTP-Header. Als Meta-Tag im HTML wird es ignoriert. Hast du schon eine Content-Security-Policy, ergänz frame-ancestors dort, statt einen zweiten CSP-Header anzulegen.

<IfModule mod_headers.c>
  Header always set X-Frame-Options "SAMEORIGIN"
  Header always set Content-Security-Policy "frame-ancestors 'self'"
</IfModule>

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

// next.config.mjs
const nextConfig = {
  async headers() {
    return [
      {
        source: "/:path*",
        headers: [
          { key: "X-Frame-Options", value: "SAMEORIGIN" },
          { key: "Content-Security-Policy", value: "frame-ancestors 'self'" },
        ],
      },
    ];
  },
};

export default nextConfig;

Typische Fehler

• ·Header gesetzt, und plötzlich funktioniert ein Buchungs- oder Shop-Widget nicht mehr, das auf einer Partnerseite eingebettet ist. Wenn deine Seite absichtlich woanders erscheinen soll, nimm frame-ancestors mit den erlaubten Domains, etwa frame-ancestors 'self' https://partner.de.
• ·X-Frame-Options: ALLOW-FROM gesetzt. Diesen Wert kennen aktuelle Browser nicht mehr, die Seite ist dann ungeschützt.