Sicherheitsheader für Webanwendungen: vollständiger Setup-Guide

Sicherheitsheader sind HTTP-Antwortfelder, die Browsern mitteilen, wie das Verhalten einer Seite eingeschränkt werden soll. Für eine Dateiübertragungs-App, die clientseitige AES-256-GCM-Verschlüsselung durchführt, sind sechs Header am wichtigsten: Strict-Transport-Security erzwingt HTTPS, Content-Security-Policy blockiert Script-Injection, X-Frame-Options verhindert Clickjacking, Referrer-Policy stoppt URL-Fragment-Lecks, Permissions-Policy deaktiviert ungenutzte Browser-APIs, und Cross-Origin-Opener-Policy isoliert den Browsing-Kontext. Diese richtig zu setzen, blockiert 80 % der praktischen clientseitigen Angriffe, ohne eine einzige Zeile JavaScript zu ändern.

HSTS und die Preload-Liste

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload weist Browser an, für zwei Jahre nie wieder über unverschlüsseltes HTTP zu verbinden. Die preload-Direktive qualifiziert Sie für Chromes HSTS-Preload-Liste (hstspreload.org), die mit dem Browser ausgeliefert wird — selbst die erste Anfrage an Ihre Domain geht über HTTPS, wodurch das initiale MITM-Fenster entfällt. Die Anmeldung ist ein Einbahnweg; die Entfernung dauert Monate. Testen Sie zunächst mit max-age=300 für einige Tage. Ein Dateiübertragungsdienst ohne HSTS-Preload ist einen DNS-Hijack davon entfernt, ein gefälschtes Upload-Formular auszuliefern.

Content Security Policy, die wirklich funktioniert

CSP ist der schwierigste Header zum Ausrollen und der wertvollste. Eine strenge Richtlinie für eine Dateiübertragungs-App sieht so aus: default-src 'none'; script-src 'self' 'wasm-unsafe-eval'; connect-src 'self' https://upload.hexatransfer.com; style-src 'self'; img-src 'self' data:; font-src 'self'; frame-ancestors 'none'; base-uri 'none'; form-action 'self'. Keine Inline-Scripts, kein eval außer wasm, keine Drittanbieter-Verbindungen. Verschieben Sie Inline-Event-Handler in addEventListener in externen Dateien. 'wasm-unsafe-eval' wird für libsodium.js benötigt; ohne es instanziiert Argon2id nicht.

Subresource Integrity für jedes Bundle

Wenn Ihr JavaScript von einem CDN wie jsDelivr oder unpkg geladen wird, fügen Sie integrity="sha384-..." Attribute zu jedem Script-Tag hinzu. Der Browser verweigert die Ausführung von Scripts, deren Hash nicht übereinstimmt — ein kompromittiertes CDN kann kein manipuliertes Bundle stillschweigend pushen. Bei selbst gehosteten Scripts, die von Ihrer eigenen Domain bereitgestellt werden, ist SRI weniger kritisch, aber dennoch vertretbar. Kombinieren Sie SRI mit CSP oder erzwingen Sie es über die Build-Pipeline. HexaTransfer veröffentlicht pro Release Hashes, damit sicherheitsbewusste Nutzer manuell verifizieren können.

X-Frame-Options und frame-ancestors

Clickjacking-Angriffe laden Ihre Upload-Seite in einem transparenten iframe über einer anderen Seite, um Nutzer dazu zu verleiten, auf „Senden" zu klicken, ohne es zu beabsichtigen. X-Frame-Options: DENY blockiert jegliches Einbetten; der moderne Ersatz ist Content-Security-Policy: frame-ancestors 'none'. Senden Sie beides — ältere Browser beachten nur den Legacy-Header, neuere bevorzugen CSP. Verwenden Sie niemals SAMEORIGIN für eine Dateiübertragungs-App; es gibt keinen legitimen Grund, Upload-UIs von einer anderen Seite aus einzubetten.

Referrer-Policy zum Stoppen von Fragment-Lecks

Browser entfernen URL-Fragmente (den #key=...-Teil, wo Ihr Entschlüsselungsschlüssel lebt) standardmäßig aus Referer-Headern, aber der Pfadteil leckt noch. Referrer-Policy: no-referrer blockiert alle Referrer-Informationen — kein Referer-Header bei ausgehenden Links, keine Cross-Origin-Lecks, kein URL-Fingerprinting durch externe Tracker. Für eine Download-Seite unter /d/7Kj9xQmN2vP8rBwLsE4fT#k=abc verhindert das, dass der Slug an externe Domains leckt, zu denen der Nutzer navigiert. Setzen Sie es websiteweit per Header; verlassen Sie sich nicht auf linkweises rel="noreferrer".

Permissions-Policy für Defense-in-Depth

Wenn Ihre App keine Kamera, kein Mikrofon, keine Geolocation oder USB-API nutzt, verweigern Sie diese explizit: Permissions-Policy: camera=(), microphone=(), geolocation=(), usb=(), bluetooth=(), accelerometer=(), magnetometer=(), gyroscope=(), payment=(). Eine XSS-Attacke, die CSP umgeht, kann trotzdem keine Webcam aktivieren, um das Gesicht des Nutzers aufzuzeichnen. Dieser Header ist günstig zu implementieren, hat keine UX-Auswirkungen für einen Dateiübertragungs-Workflow und signalisiert Security-Reviewern, dass Sie über Sandboxing nachgedacht haben.

Cross-Origin-Isolations-Header

Für den Zugriff auf hochauflösende Timer und SharedArrayBuffer (benötigt von manchen wasm-Krypto-Implementierungen) erfordern Browser Cross-Origin-Isolation über Cross-Origin-Opener-Policy: same-origin und Cross-Origin-Embedder-Policy: require-corp. Diese Header verhindern auch Spectre-artige Seitenkanal-Angriffe, die AES-Schlüssel aus benachbarten Ursprüngen lecken könnten. Der Kompromiss: Eingebettete Drittanbieter-Ressourcen (YouTube-Videos, Stripe-Checkout) brechen, wenn sie nicht Cross-Origin-Resource-Policy: cross-origin liefern. Für eine reine Dateiübertragungs-App ohne Drittanbieter-Einbettungen ist die Isolation kostenlos.

Cache-Control für sensible Seiten

Die Download-Bestätigungsseite könnte einen kurzlebigen Entschlüsselungsschlüssel oder ein Session-Token anzeigen. Verhindern Sie Caching: Cache-Control: no-store, must-revalidate und Pragma: no-cache. Verlassen Sie sich nicht nur auf no-cache — das erlaubt Revalidierung gegen den Ursprung, was bedeutet, dass Caching noch stattfindet. Für das JavaScript-Bundle der Upload-Seite gilt das Gegenteil: langes max-age mit inhaltlich gehashten Dateinamen (/js/main-a7b3c9.js), damit CDN-Caching ohne Invalidierungsprobleme funktioniert. Wenden Sie Header nach Pfad differenziert an.

X-Content-Type-Options und MIME-Sniffing

X-Content-Type-Options: nosniff verhindert, dass Browser MIME-Typen anhand des Inhalts erraten. Ohne das könnte eine .txt-Datei, die ein Angreifer hochgeladen hat und <script> enthält, als HTML gerendert werden, wenn sie zurückgeliefert wird. Kombinieren Sie für einen Transferdienst, der nutzergesteuerte Downloads bereitstellt, nosniff mit Content-Disposition: attachment; filename="...", damit der Browser herunterlädt statt zu rendern. Validieren Sie Dateinamen serverseitig gegen Path Traversal (../../../etc/passwd); vertrauen Sie den Upload-Metadaten nur für die Anzeige.

Überwachung und CSP-Reports

Setzen Sie CSP zunächst im report-only-Modus ein, sammeln Sie eine Woche lang Verstöße an einem report-uri-Endpunkt, beheben Sie legitime Probleme, und wechseln Sie dann zur Durchsetzung. Verwenden Sie Content-Security-Policy-Report-Only zur Beobachtung, wechseln Sie zu Content-Security-Policy für die Durchsetzung. Der Report-Endpunkt empfängt JSON-POSTs, die jeden Verstoß beschreiben: blockierte URI, verletzte Direktive, Quelldatei, Zeilennummer. Dienste wie Report URI oder ein selbst gehosteter Sentry sammeln diese. Überprüfen Sie wöchentlich — echte Angriffe zeigen sich als ungewöhnliche blockierte URIs, die Sie noch nie gesehen haben.

Ihre Arbeit bewerten

Führen Sie Ihre Produktions-URL durch securityheaders.com und Mozilla Observatory. Eine A- oder A+-Bewertung ist keine Perfektion, aber Mindeststandard. Die meisten Dateiübertragungs-Konkurrenten erzielen B oder schlechter, weil sie Permissions-Policy vergessen oder 'unsafe-inline' in CSP erlauben. Ein kleiner Dienst kann WeTransfers Sicherheitsheader-Bewertung leicht übertreffen; die Header kosten nichts hinzuzufügen, und das Audit-Trail für „warum ist Ihre CSP nicht streng"-Gespräche mit SOC-2-Auditoren ist kürzer, wenn Sie von Anfang an streng waren.

Auf hexatransfer.com testen — kostenlos, ohne Konto, bis 10 GB.