Clickjacking-Schutz in Spring Boot

Spring Security setzt X-Frame-Options: DENY als Default -- Anpassung auf SAMEORIGIN per frameOptions() und Migration zu CSP frame-ancestors.

Spring Boot · Schritt für Schritt

Clickjacking-Schutz in Spring Boot

X-Frame-Options schuetzt gegen Clickjacking-Angriffe, bei denen Ihre Seite in einem unsichtbaren iframe geladen wird. Der Header ist mit 10 von 166 Punkten relevant im Wolf-Agents Web Security Check.

Spring Security setzt X-Frame-Options: DENY automatisch als Default. Das bedeutet: Ihre Anwendung kann nicht in iframes eingebettet werden. Falls Sie iframes benoetigen (z.B. eingebettete Dashboards oder Payment-Widgets), müssen Sie auf SAMEORIGIN ändern per frameOptions(fo -> fo.sameOrigin()).

Bei der Konfiguration von Clickjacking-Schutz in Spring Boot ist es wichtig, die Wechselwirkung mit anderen Security-Headern zu beruecksichtigen. Spring Security verwaltet mehrere Header gleichzeitig ueber die headers()-DSL. Wenn Sie eine eigene SecurityFilterChain definieren, muessen Sie sicherstellen, dass alle gewuenschten Header explizit konfiguriert sind -- Spring Security setzt nur die Header, die in der aktiven Chain definiert sind.

1 Schritt 1 von 3

Spring Security Default anpassen

Spring Security setzt X-Frame-Options: DENY automatisch. Prüfen Sie ob Ihre Anwendung iframes benoetigt und passen Sie den Default bei Bedarf an. Die frameOptions()-DSL bietet drei Optionen: deny(), sameOrigin() und disable().

Beachten Sie, dass der Header auf allen Seiten konsistent gesetzt sein muss. Eine Luecke auf einer einzigen Seite kann ausreichen, damit Angreifer diese Seite als Einstiegspunkt nutzen. Testen Sie die Konfiguration daher auf verschiedenen Pfaden und Seitentypen Ihrer Anwendung.

SecurityConfig.java Produktiv
// SecurityConfig.java -- X-Frame-Options anpassen
@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http)
        throws Exception {
    http.headers(headers -> headers
        // Default DENY auf SAMEORIGIN aendern
        .frameOptions(fo -> fo.sameOrigin())
        // Zusaetzlich CSP frame-ancestors
        .contentSecurityPolicy(csp -> csp
            .policyDirectives("frame-ancestors 'self'"))
    );
    return http.build();
}

// X-Frame-Options komplett deaktivieren
// (nur wenn CSP frame-ancestors gesetzt ist)
// http.headers(h -> h.frameOptions(fo -> fo.disable()));
DENY vs. SAMEORIGIN

DENY blockiert alle iframes. SAMEORIGIN erlaubt iframes von der gleichen Domain. Für Zahlungsanbieter (Stripe, PayPal) die iframes nutzen, brauchen Sie mindestens SAMEORIGIN.

2 Schritt 2 von 3

Header verifizieren

Prüfen Sie den X-Frame-Options-Header per curl. Der Wert muss DENY oder SAMEORIGIN sein -- ALLOW-FROM ist deprecated und wird von modernen Browsern nicht unterstuetzt.

Terminal Verifizierung
# X-Frame-Options pruefen
curl -sI http://localhost:8080 | grep -i x-frame-options

# Erwartete Ausgabe (Default):
x-frame-options: DENY

# Oder nach Anpassung:
x-frame-options: SAMEORIGIN
Der Wolf-Agents Web Security Check prüft diesen Header automatisch und bewertet ihn mit bis zu 10 Punkten.
3 Schritt 3 von 3

Migration zu CSP frame-ancestors

Für granulare Kontrolle migrieren Sie zu CSP frame-ancestors. Damit können Sie spezifische Domains erlauben, die Ihre Seite einbetten duerfen. In modernen Browsern hat CSP frame-ancestors Vorrang vor X-Frame-Options.

Setzen Sie beide Header für maximale Abwaertskompatibilitaet. Aeltere Browser unterstuetzen CSP frame-ancestors nicht und fallen auf X-Frame-Options zurück.

Häufige Fehler bei Clickjacking-Schutz in Spring Boot

Spring Security Default überschreibt Custom-Config

Bei mehreren SecurityFilterChains kann eine mit niedrigerer @Order den X-Frame-Options-Wert überschreiben. Prüfen Sie die @Order-Annotationen aller SecurityFilterChain-Beans.

iframe-basierte Payment-Widgets blockiert

Stripe, PayPal und Klarna nutzen iframes für Checkout-Widgets. Mit DENY funktionieren diese nicht. Aendern Sie auf SAMEORIGIN oder verwenden Sie CSP frame-ancestors.

X-Frame-Options und CSP frame-ancestors gleichzeitig

Wenn beide Header gesetzt sind, hat CSP frame-ancestors in modernen Browsern Vorrang. Setzen Sie beide für Abwaertskompatibilitaet -- die Werte müssen konsistent sein.

Mehrere SecurityFilterChains vergessen

Bei separaten SecurityFilterChain-Beans fuer API, Web und Actuator muss jede Chain Clickjacking-Schutz separat konfigurieren. Header werden nicht zwischen Chains vererbt -- fehlende Konfiguration bedeutet fehlende Header.

Compliance-Relevanz

Die korrekte Implementierung von Clickjacking-Schutz ist nicht nur eine technische Best Practice, sondern eine Anforderung, die bei Sicherheitsaudits und Penetrationstests regelmaessig geprueft wird. Fehlende oder falsch konfigurierte Header koennen zu Audit-Findings fuehren und die Zertifizierung gefaehrden.

Clickjacking-Schutz erfuellt Anforderungen mehrerer Compliance-Frameworks.

PCI DSS 4.0 Anforderung 6.5.9 -- Schutz vor Clickjacking-Angriffen
NIS2 Art. 21(e) -- Sicherheit bei Entwicklung und Wartung
BSI APP.3.1 -- Webserver-Absicherung mit Security Headern

Wie steht Ihre Domain bei Clickjacking-Schutz?

Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 166 Prüfpunkte.