HTTP-Sicherheitsheader, die jede Unternehmenswebsite senden sollte

HTTP-Sicherheitsheader sind Anweisungen, die Ihr Webserver mit jeder Seite mitschickt. Sie sagen dem Browser, wie er mit Ihrer Website umgehen soll: immer HTTPS verwenden, anderen Websites nicht erlauben, Ihre Seiten in einen Frame einzubetten, keine Dateitypen raten, Skripte nur aus vertrauenswürdigen Quellen laden. Sie kosten keine Performance und werden einmalig in der Server- oder CDN-Konfiguration gesetzt.

Die Kurzfassung für die meisten Unternehmenswebsites: Senden Sie Strict-Transport-Security, Content-Security-Policy (mindestens mit frame-ancestors), X-Content-Type-Options, Referrer-Policy und Permissions-Policy, setzen Sie Cookies mit den richtigen Attributen und entfernen Sie Header, die Ihre Softwareversionen verraten. Die empfohlenen Werte unten folgen dem OWASP HTTP Headers Cheat Sheet und MDN.

Fehlende Header sind für sich allein selten ein Notfall. Sie zeigen aber, wie sorgfältig eine Website konfiguriert ist, und sie schließen ganze Klassen von Angriffen im Browser aus.

So prüfen Sie Ihre Header

Fragen Sie den Server nach den Headern Ihrer Startseite:

curl -sI https://yourcompany.com/

Prüfen Sie jeden Hostnamen, nicht nur den Hauptnamen: Shop, Login, Kundenportal und alle alten Staging-Server, die noch antworten. Header, die in der Anwendung gesetzt werden, fehlen oft auf Fehlerseiten, bei Weiterleitungen und bei statischen Dateien. Testen Sie deshalb mehrere unterschiedliche URLs.

Diese Header lohnen sich

Strict-Transport-Security (HSTS)

Weist den Browser an, für Ihre Domain eine festgelegte Zeit lang ausschließlich HTTPS zu verwenden. So kann ein Besucher nicht unbemerkt auf HTTP herabgestuft werden.

Strict-Transport-Security: max-age=63072000; includeSubDomains

max-age wird in Sekunden angegeben. Ergänzen Sie includeSubDomains nur, wenn jede Subdomain über HTTPS funktioniert. Für die Aufnahme in die Preload-Listen der Browser verlangt hstspreload.org ein max-age von mindestens 31536000 (1 Jahr), includeSubDomains und preload. Preloading lässt sich nur schwer rückgängig machen, fügen Sie es also zuletzt hinzu.

Content-Security-Policy (CSP)

Legt fest, aus welchen Quellen die Seite Skripte, Stylesheets, Bilder und Frames laden darf. Eine gute Policy ist die stärkste Abwehr gegen Cross-Site-Scripting auf Browserseite, muss aber auf Ihre Website zugeschnitten sein. Beginnen Sie im Berichtsmodus mit Content-Security-Policy-Report-Only, beobachten Sie, was blockiert würde, und setzen Sie die Policy dann durch.

Schon vor einer vollständigen Policy ist eine Direktive einfach und nützlich:

Content-Security-Policy: frame-ancestors 'self'

frame-ancestors steuert, welche Websites Ihre Seiten einbetten dürfen, und verhindert so Clickjacking. Die Direktive muss als Header gesendet werden, in einem <meta>-Tag funktioniert sie nicht.

X-Frame-Options

Der ältere Weg, Framing zu blockieren. OWASP empfiehlt, wo möglich frame-ancestors zu verwenden und X-Frame-Options: DENY (oder SAMEORIGIN) als Rückfallebene für ältere Browser zu senden.

X-Content-Type-Options

X-Content-Type-Options: nosniff

Verhindert, dass der Browser den Typ einer Datei errät, damit eine hochgeladene Datei nicht als Skript ausgeführt werden kann. Achten Sie darauf, dass Ihre Content-Type-Header auf der ganzen Website korrekt sind.

Referrer-Policy

Referrer-Policy: strict-origin-when-cross-origin

Begrenzt, wie viel von Ihren URLs an andere Websites weitergegeben wird, wenn Besucher auf Links klicken. Das ist wichtig, wenn URLs Bestellnummern, Tokens oder Suchbegriffe enthalten.

Permissions-Policy

Permissions-Policy: geolocation=(), camera=(), microphone=()

Schaltet Browserfunktionen ab, die Ihre Website nicht nutzt, damit ein eingeschleustes Skript sie nicht anfordern kann.

Auch Cookies brauchen Attribute

Session-Cookies sollten mit Secure (nur HTTPS), HttpOnly (nicht aus JavaScript lesbar) und SameSite=Lax oder Strict gesetzt werden:

Set-Cookie: session=...; Secure; HttpOnly; SameSite=Lax; Path=/

Prüfen Sie auch die Domain des Cookies. Ein Cookie für .yourcompany.com ist für jede Subdomain lesbar. Das wird relevant, falls eine davon einmal über einen verwaisten DNS-Eintrag übernommen wird.

Header, die Sie entfernen oder nicht mehr verwenden sollten

• Server und X-Powered-By mit Versionsnummern, etwa Apache/2.4.41 oder PHP/7.4.3. Sie verraten jedem genau, welche Software in welcher Version er nachschlagen muss. OWASP empfiehlt, X-Powered-By zu entfernen und Server nichtssagend zu machen.
• X-XSS-Protection. MDN führt den Header als veraltet und nicht standardisiert und weist darauf hin, dass er in ansonsten sicheren Websites Probleme verursachen kann. OWASP empfiehlt, ihn nicht zu setzen oder X-XSS-Protection: 0 zu senden und sich auf CSP zu verlassen.
• Expect-CT. OWASP rät davon ab und empfiehlt, ihn aus bestehenden Konfigurationen zu entfernen.

Wo Sie die Header setzen

Setzen Sie Header an einer Stelle, die jede Antwort abdeckt: im Webserver (nginx add_header ... always;, Apache Header always set), im CDN oder in den Header-Einstellungen der Hosting-Plattform. Das Schlüsselwort always ist bei nginx wichtig: Ohne es werden Header nur bei erfolgreichen Antworten und Weiterleitungen gesetzt, nicht auf Fehlerseiten.

Kurze Checkliste

• Führen Sie curl -sI für jeden Ihrer Hostnamen aus.
• Ergänzen Sie HSTS, X-Content-Type-Options, Referrer-Policy, Permissions-Policy und frame-ancestors.
• Führen Sie eine vollständige CSP zuerst im Berichtsmodus ein.
• Setzen Sie Secure, HttpOnly und SameSite bei Session-Cookies.
• Entfernen Sie Versionsnummern aus Server und X-Powered-By, und verzichten Sie auf X-XSS-Protection und Expect-CT.
• Prüfen Sie erneut nach jeder Änderung an Server, CDN oder Plattform.

Wenn Sie schon in der Serverkonfiguration sind, stellen Sie auch sicher, dass sie keine offen erreichbaren .env-, .git- oder Backup-Dateien ausliefert.

Wo Datahorses ins Spiel kommt

Datahorses überwacht Ihre Websites jeden Tag von außen und prüft, was Browser und Angreifer tatsächlich erhalten: fehlende Sicherheitsheader, Cookies ohne Secure, HttpOnly oder SameSite, Server, die ihre Versionen verraten, und gemischte HTTP-Inhalte auf HTTPS-Seiten. Wir greifen nicht auf Ihre Systeme zu und benötigen keinen Zugang. Zu jedem Fund erhalten Sie die genaue Konfigurationsänderung für Ihren Entwickler. Sehen Sie sich die vollständige Liste dessen an, was wir überwachen, oder fordern Sie ein Angebot an.