Fehlende X-Frame-Options (Clickjacking)

Worum geht es

Ihre Website sendet weder den Header X-Frame-Options noch hat sie in der CSP frame-ancestors gesetzt. Ohne diese kann Sie jeder in einen <iframe> auf einer fremden Website einbetten.

Warum das ein Problem ist

Der Angriff heißt Clickjacking. Der Angreifer baut eine harmlos aussehende Seite, legt darauf Ihre Website in einem iframe ab, macht diesen mit einem CSS-Trick durchsichtig und platziert darüber einen Button „iPhone gewinnen“. Der Besucher klickt — und hat in Wirklichkeit auf „Konto löschen“ auf Ihrer Website geklickt, wo er angemeldet ist.

Praktische Szenarien:

Passwortänderung (POST /change-password desselben Kontos, aus einem CSRF-geschützten Formular).
One-Click-Kauf — untergeschobener Klick auf „Confirm purchase“.
Genehmigung einer OAuth-Anwendung.

Wie man es behebt

Es gibt zwei Header — Sie können beide senden:

X-Frame-Options (älter, von allen Browsern unterstützt)

X-Frame-Options: DENY
# oder
X-Frame-Options: SAMEORIGIN

DENY — niemand darf Sie in einen iframe einbetten, auch Sie selbst nicht.
SAMEORIGIN — in einen iframe nur von der eigenen Domain.

CSP frame-ancestors (moderner, granularer)

Content-Security-Policy: frame-ancestors 'none';
# oder:
Content-Security-Policy: frame-ancestors 'self';
# oder mit Allowlist:
Content-Security-Policy: frame-ancestors 'self' https://partner.example.cz;

Wenn Sie eine CSP haben, hat frame-ancestors Vorrang vor X-Frame-Options.

Konkrete Konfiguration

nginx:

add_header X-Frame-Options "DENY" always;
add_header Content-Security-Policy "frame-ancestors 'none'" always;

Apache:

Header always set X-Frame-Options "DENY"
Header always set Content-Security-Policy "frame-ancestors 'none'"

Wann NICHT DENY?

Manchmal muss eine Website in einem iframe stehen — im eigenen Online-Shop (eingebettetes Widget), in einem Partnerportal, in einer White-Label-Lösung. In diesem Fall verwenden Sie nicht DENY, sondern geben eine konkrete Allowlist über frame-ancestors an.