Permissions Policy in Spring Boot

Browser-APIs per SecurityFilterChain einschraenken -- Kamera, Mikrofon, Geolocation und weitere APIs gezielt sperren oder freigeben.

Spring Boot · Schritt für Schritt

Permissions Policy in Spring Boot

Permissions Policy kontrolliert, welche Browser-APIs Ihre Anwendung und eingebettete Drittanbieter-Inhalte nutzen duerfen. Der Header ist mit 10 von 166 Punkten relevant im Wolf-Agents Web Security Check.

Spring Security setzt Permissions Policy nicht automatisch. Konfigurieren Sie den Header per permissionsPolicy()-DSL in der SecurityFilterChain. Die Syntax verwendet Structured Headers Notation mit =() fuer leere Allowlists. Anders als bei CSP oder HSTS gibt es keine Spring-Security- Default-Konfiguration -- ohne explizite Konfiguration fehlt der Header komplett.

Die Permissions Policy ersetzt den veralteten Feature-Policy-Header. Spring Security 6.x unterstuetzt ausschliesslich die neue Syntax. Die wichtigsten APIs zum Sperren sind: camera, microphone, geolocation, payment, usb, magnetometer, gyroscope und accelerometer.

1 Schritt 1 von 3

Permissions Policy konfigurieren

Verwenden Sie die permissionsPolicy()-DSL in der SecurityFilterChain, um Browser-APIs wie Kamera, Mikrofon und Geolocation gezielt einzuschraenken. Jede API wird einzeln konfiguriert -- leere Klammern () sperren die API vollstaendig. Diese Konfiguration gilt fuer alle Responses, die durch die SecurityFilterChain laufen.

SecurityConfig.java Produktiv
// SecurityConfig.java -- Permissions Policy
@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http)
        throws Exception {
    http.headers(headers -> headers
        .permissionsPolicy(pp -> pp
            .policy("camera=(), microphone=(), geolocation=(), "
                + "payment=(), usb=(), magnetometer=(), "
                + "gyroscope=(), accelerometer=()"))
    );
    return http.build();
}
Neue vs. alte Syntax

Der Header Feature-Policy ist deprecated. Verwenden Sie Permissions-Policy mit der neuen Syntax: camera=() statt camera 'none'. Spring Security 6.x unterstuetzt nur die aktuelle Syntax.

2 Schritt 2 von 3

Header verifizieren

Pruefen Sie den Permissions-Policy-Header per curl. Jede gesperrte API erscheint als feature=() in der Ausgabe. Fehlende APIs im Header bedeuten, dass diese API nicht eingeschraenkt ist. In Chrome DevTools koennen Sie die aktive Policy auch unter Application > Frames einsehen.

Terminal Verifizierung
# Permissions-Policy pruefen
curl -sI http://localhost:8080 | grep -i permissions-policy

# Erwartete Ausgabe:
permissions-policy: camera=(), microphone=(), geolocation=(), payment=(), usb=(), magnetometer=(), gyroscope=(), accelerometer=()

# Im Browser pruefen (DevTools > Application > Frames):
# Chrome zeigt dort die aktive Permissions Policy an
Der Wolf-Agents Web Security Check prueft diesen Header automatisch und bewertet ihn mit bis zu 10 Punkten.
3 Schritt 3 von 3

APIs gezielt freigeben

Fuer WebRTC-Anwendungen oder Video-Konferenzen geben Sie Kamera und Mikrofon gezielt frei: camera=(self), microphone=(self). Alle anderen APIs bleiben gesperrt. Verwenden Sie Spring Profiles fuer unterschiedliche Konfigurationen pro Umgebung. Die Freigabe mit (self) beschraenkt den Zugriff auf die eigene Domain -- eingebettete iframes haben keinen Zugriff.

SecurityConfig.java WebRTC
// SecurityConfig.java -- WebRTC: Kamera + Mikrofon freigeben
@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http)
        throws Exception {
    http.headers(headers -> headers
        .permissionsPolicy(pp -> pp
            .policy("camera=(self), microphone=(self), "
                + "geolocation=(), payment=(), "
                + "usb=(), magnetometer=(), "
                + "gyroscope=(), accelerometer=()"))
    );
    return http.build();
}
Testen Sie die Konfiguration in allen Umgebungen. Verwenden Sie Spring Profiles fuer umgebungsspezifische Header-Werte.

Häufige Fehler bei Permissions Policy in Spring Boot

Alte Feature-Policy Syntax verwendet

Der Header Feature-Policy ist deprecated. Verwenden Sie Permissions-Policy mit der neuen Syntax: camera=() statt camera 'none'.

Permissions Policy blockiert eingebettete Karten

Wenn Sie Google Maps oder andere Karten-Widgets einbetten, verwenden Sie geolocation=(self) statt geolocation=(). Leere Klammern blockieren die API vollstaendig.

Actuator-Endpoints brauchen keine Permissions Policy

Actuator-Endpoints liefern JSON und rendern keine Browser-Inhalte. Eine Permissions Policy auf Actuator-Endpoints ist technisch unnoetig, aber auch nicht schaedlich.

Permissions Policy nur im Haupt-SecurityFilterChain

Bei mehreren SecurityFilterChain-Beans (z.B. fuer API und Web) muss jede Chain die Permissions Policy separat konfigurieren. Der Header wird nicht automatisch vererbt.

Compliance-Relevanz

Die korrekte Konfiguration von Permissions Policy erfuellt Anforderungen mehrerer Compliance-Frameworks und ist besonders relevant fuer Anwendungen, die Browser-APIs wie Kamera oder Mikrofon nutzen.

PCI DSS 4.0 Anforderung 6.4.3 -- Kontrolle von Browser-APIs auf Zahlungsseiten
NIS2 Art. 21(e) -- Sicherheit bei Entwicklung und Wartung von Informationssystemen
BSI APP.3.1 -- Einschraenkung von Browser-Funktionalitaeten

Wie steht Ihre Domain bei Permissions Policy?

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