Jeder Response-Header-Check des Header-Moduls: was geprüft wird, warum es zählt und wie bewertet wird – von HSTS und CSP-Qualität bis zu Cookie-Flags und Informationslecks.
Jetzt Domain prüfen →
Stand: Juli 2026 · 31 Checks dokumentiert
HTTP-Antwort erreichbar #
Die Header-Checks bewerten die Antwort eines echten Seitenaufrufs (https://…/). Lässt sich keine HTTP-Antwort abrufen – Verbindung abgelehnt, Timeout oder ein ungültiges Zertifikat, das die Anfrage abbricht –, gibt es keine Header zum Benoten.
BewertungErscheint nur, wenn der Seitenaufruf scheitert: skip; das Modul wird als nicht benotbar gemeldet, statt bei fehlenden Daten mit F benotet zu werden.
BehebungSicherstellen, dass die Seite HTTPS-Anfragen mit einem gültigen Zertifikat und in angemessener Zeit beantwortet, dann den Scan erneut ausführen. Das Website-Modul zeigt das zugrundeliegende TLS-Problem meist im Detail.
Redirect-Ziel #
Der Scanner folgt Redirects, bevor er Header analysiert. Endet die Kette auf einer anderen Domain, beschreiben alle Header-Findings diesen finalen Host, nicht die gescannte Domain. Endet sie auf unverschlüsseltem http://, ist die gesamte Seite (Inhalte, Cookies, Logins) trotz HTTPS-Start Man-in-the-Middle-Angriffen ausgesetzt.
Bewertungfail + Cap C, wenn die finale URL http:// ist (HTTPS→HTTP-Downgrade); info, wenn der Redirect lediglich auf einer anderen registrierbaren Domain endet. Wird nicht angezeigt, wenn die Seite per HTTPS auf der gescannten Domain bleibt.
BehebungJeden Redirect auf http:// entfernen und die finale Seite über HTTPS ausliefern. Bei domainübergreifenden Redirects für aussagekräftige Ergebnisse direkt die finale Domain scannen.
Strict-Transport-Security (HSTS) #
HSTS weist den Browser an, die Domain von da an ausschließlich über HTTPS aufzurufen, und verhindert so SSL-Stripping-/Downgrade-Angriffe sowie unsichere Erstbesuche.
Bewertungpass bei max-age ≥ 1 Jahr; warn bei kürzerer Lebensdauer; fehlend → fail. Sonderfall: max-age=0 → fail, denn das LÖSCHT aktiv eine bestehende HSTS-Policy im Browser. Gewicht 2.
BehebungDen Header setzen: Strict-Transport-Security: max-age=63072000; includeSubDomains; preload (erst nachdem HTTPS auf allen Subdomains verifiziert ist).
HSTS-Preload #
Domains auf der HSTS-Preload-Liste der Browser werden von Anfang an nur über HTTPS angesprochen – schon beim allerersten Besuch, bevor irgendein Header gesehen wurde. Dieser Punkt prüft zwei unabhängige Fakten: (1) Eignung – erfüllt der aktuelle Header die Kriterien von hstspreload.org (max-age ≥ 1 Jahr, includeSubDomains, preload)? und (2) Listenstatus – steht die Domain tatsächlich auf der Preload-Liste, live abgefragt über die offizielle Status-API von hstspreload.org? Der kritische Fall ist, auf der Liste zu stehen, während der Header nicht mehr konform ist (z. B. wurde preload später entfernt): ausgelieferte Browser erzwingen weiterhin HTTPS, aber der Eintrag wird für die automatische Entfernung freigegeben – danach verschwindet der Erstbesuchsschutz stillschweigend –, und der Header hätte nie ohne den offiziellen Entfernungsprozess geändert werden dürfen.
Bewertunggood, wenn preloaded mit weiterhin konformem Header, oder geeignet-aber-noch-nicht-eingereicht (das Einreichen ist optional, Gewicht 0); info, wenn weder preloaded noch bereits geeignet; warn (Gewicht 1) bei einer ausstehenden Einreichung/Entfernung, deren Header nicht mehr passt; fail (Gewicht 2), wenn die Domain auf der Preload-Liste steht, der aktuelle Header aber nicht konform ist.
BehebungFür die Aufnahme in die Preload-Liste: alle Kriterien erfüllen und auf hstspreload.org einreichen. Wenn bereits preloaded, max-age=63072000; includeSubDomains; preload unverändert weiter ausliefern; zum Verlassen der Liste hstspreload.org/removal/ nutzen, statt nur den Header zu entfernen.
Content-Security-Policy #
Die CSP ist die wirksamste Schutzschicht gegen Cross-Site-Scripting (XSS): Sie legt fest, welche Quellen Skripte, Styles usw. laden dürfen. Eine reine Host-Allowlist mit unsafe-inline ist oft umgehbar; Nonce-/Hash-basierte Policies mit strict-dynamic sind stark. Das Detail meldet zusätzlich, ob die strengen internet.nl-Kriterien erfüllt sind (keine unsichere Quelle in IRGENDEINER Direktive inkl. style-src, keine http:-/bloßen https:-/Wildcard-Hosts, eingeschränkte default-src/frame-ancestors/base-uri/form-action) – relevant für eine 100%-Punktzahl bei internet.nl, ohne Einfluss auf die Note hier.
Bewertungpass bei einer starken (Nonce/Hash) CSP oder einer Allowlist ohne unsichere Quellen; warn bei unsafe-inline/Wildcards ohne Nonce oder nur Report-Only; fail, wenn keine CSP gesetzt ist. Gewicht 2.
BehebungEine Nonce-/Hash-basierte CSP mit strict-dynamic verwenden; unsafe-inline/unsafe-eval vermeiden (Inline-Styles → CSS-Dateien oder element.style/CSSOM).
CSP-Härtung (object-src / base-uri / form-action) #
Drei Direktiven härten eine CSP über Skript-Quellen hinaus gegen Injection: object-src 'none' blockiert veraltete Plugin-Einbettungen (<object>/<embed>). base-uri und form-action haben KEINEN Fallback auf default-src – sind sie nicht gesetzt, kann ein injiziertes <base>-Tag relative URLs auf einen fremden Server umlenken, und ein injiziertes <form action> kann Daten an fremde Server senden (Phishing/Exfiltration), selbst bei strikter default-src.
Bewertungpass, wenn alle drei eingeschränkt sind (object-src/default-src 'none'; base-uri 'none'/'self'; form-action 'self'/'none'); sonst warn mit Auflistung der fehlenden Direktiven. Nur bei einer durchgesetzten CSP. Gewicht 2.
Behebungobject-src 'none'; base-uri 'none'; form-action 'self' zur CSP hinzufügen.
CSP upgrade-insecure-requests #
Stuft unsichere HTTP-Ressourcen-Anfragen automatisch auf HTTPS hoch und verhindert so Mixed Content. Das ältere block-all-mixed-content ist deprecated.
BewertungInformativ (Gewicht 0): zeigt an, ob die Direktive aktiv ist.
Behebungupgrade-insecure-requests zur CSP hinzufügen (ersetzt block-all-mixed-content).
CSP Trusted Types #
Trusted Types (require-trusted-types-for 'script') sind die stärkste Schutzschicht gegen DOM-basiertes XSS: Gefährliche DOM-Sinks akzeptieren dann nur noch geprüfte Werte.
BewertungPositives Info-Signal (Gewicht 0) – kein Abzug bei Fehlen (fortgeschritten).
BehebungOptional require-trusted-types-for 'script' (+ trusted-types) setzen.
CSP sandbox #
Die sandbox-Direktive schränkt das Dokument zusätzlich ein (wie das iframe-sandbox-Attribut). Vorsicht: allow-scripts + allow-same-origin zusammen hebeln die Sandbox weitgehend aus.
Bewertunggood bei restriktiver Nutzung; warn bei allow-scripts + allow-same-origin. Gewicht 0.
Behebungallow-scripts und allow-same-origin nicht gemeinsam erlauben.
CSP-Violation-Reporting #
CSP-Verstöße können gemeldet werden – in der modernen Form via report-to <group> (verweist auf einen definierten Reporting-Endpunkt), in der veralteten Form via report-uri <url>. Verweist report-to auf eine nicht definierte Gruppe, gehen alle Reports stillschweigend verloren.
Bewertungpass bei gültigem report-to; warn, wenn report-to auf einen nicht definierten Endpunkt zeigt; info, wenn nur das veraltete report-uri verwendet wird. Gewicht 0.
Behebungreport-to auf eine in Reporting-Endpoints definierte Gruppe setzen (für die Übergangszeit zusätzlich report-uri ergänzen).
X-Content-Type-Options: nosniff #
Verhindert MIME-Sniffing – der Browser interpretiert Antworten dann strikt nach dem deklarierten Content-Type, statt zu „raten“, was bestimmte XSS-Tricks blockiert.
Bewertungpass bei nosniff; sonst fail. Gewicht 1.
BehebungDen Header setzen: X-Content-Type-Options: nosniff.
Clickjacking-Schutz #
Verhindert, dass die Seite in einem fremden Frame eingebettet und für Clickjacking missbraucht wird – via X-Frame-Options oder in der modernen Form via CSP frame-ancestors.
BewertungDer WERT zählt: pass bei DENY/SAMEORIGIN oder CSP frame-ancestors mit none/self/Host-Allowlist; warn bei ALLOW-FROM (von modernen Browsern ignoriert) oder frame-ancestors */Scheme-Wildcard; fail, wenn beides fehlt. Gewicht 1.
BehebungX-Frame-Options: DENY oder CSP frame-ancestors 'none' setzen (frame-ancestors ist die moderne, mächtigere Variante).
Referrer-Policy #
Steuert, wie viel von der Ursprungs-URL beim Verlassen der Seite an Dritte gesendet wird. Einige Werte sind unsicher: unsafe-url sendet immer die vollständige URL, und no-referrer-when-downgrade leakt sie bei einem HTTPS→HTTP-Downgrade.
BewertungDer WERT zählt (nicht nur das Vorhandensein): pass bei no-referrer / same-origin (schützen die Privatsphäre vollständig) sowie strict-origin / strict-origin-when-cross-origin (pass mit Empfehlung zur Verschärfung – internet.nl stuft diese beiden nur als Empfehlung ein); warn bei origin / origin-when-cross-origin / no-referrer-when-downgrade / unsafe-url oder fehlendem Header. Bei mehreren (Fallback-)Werten zählt der letzte vom Browser verstandene. Gewicht 1.
BehebungReferrer-Policy: no-referrer oder same-origin setzen; strict-origin-when-cross-origin ist ein akzeptables Minimum.
Permissions-Policy #
Deaktiviert gezielt mächtige Browser-Funktionen (Kamera, Mikrofon, Standort …) und reduziert die Angriffsfläche – auch für eingebettete Inhalte. Allowlist-Syntax: () = aus, self = nur eigene Domain, * = überall (Risiko), (self "https://…") = Allowlist.
Bewertungpass, wenn die Kern-Features (camera/microphone/geolocation/payment/usb) deaktiviert sind; warn bei Wildcard * auf einem Kern-Feature, fehlendem Header, leeren/permissiven Werten oder veralteter Feature-Policy-Syntax. Weitere Hochrisiko-Features (display-capture, serial, hid, bluetooth …) werden ebenfalls aufgeführt. Gewicht 1.
BehebungNicht benötigte Features auf () setzen, z. B. Permissions-Policy: camera=(), microphone=(), geolocation=().
Cross-Origin-Isolation (COOP/COEP) #
COOP isoliert den Browsing-Kontext von cross-origin geöffneten Fenstern und erschwert XS-Leaks. Entscheidend ist der Wert: unsafe-none bietet keinen Schutz. VOLLE Cross-Origin-Isolation (für SharedArrayBuffer/präzise Timer) erfordert zusätzlich COEP require-corp/credentialless; CORP schützt eigene Ressourcen davor, von fremden Seiten eingebunden zu werden. Der COEP/CORP-Status wird als Kontext im selben Finding ausgewiesen – er ist für viele Seiten optional und kann bestehende Funktionen brechen.
BewertungNur informativ – geht NICHT in die Note ein. COOP/COEP/CORP sind aufkommende Header: securityheaders.com führt sie als „Upcoming“, Mozilla Observatory bewertet sie nicht, internet.nl testet sie nicht, und COOP same-origin zu verlangen kann auf gewöhnlichen Seiten OAuth-/Payment-Popups brechen. Ein schützender COOP-Wert (same-origin/same-origin-allow-popups) erhält einen grünen Haken (good); unsafe-none oder ein fehlender Header ist neutrales info. Beides beeinflusst die Note nicht. COEP/CORP werden als Kontext ausgewiesen.
BehebungNur optionales Hardening. Cross-Origin-Opener-Policy: same-origin setzen, wenn Cross-Origin-Isolation benötigt wird (SharedArrayBuffer, präzise Timer); für volle Isolation zusätzlich Cross-Origin-Embedder-Policy: require-corp und passende CORP-Header setzen. Für eine typische Website nicht erforderlich.
Origin-Agent-Cluster #
Mit Origin-Agent-Cluster: ?1 bittet die Seite den Browser, sie in einen origin-isolierten Prozess zu legen. Das erschwert Spectre-artige Seitenkanalangriffe zwischen Origins.
BewertungInformativ (Gewicht 0), falls gesetzt.
BehebungOptional Origin-Agent-Cluster: ?1 setzen.
Document-Policy #
Document-Policy steuert dokumentweite Features (z. B. erzwungene Bildkompression, überdimensionierte Bilder) – verwandt mit der Permissions-Policy, aber für Dokumenteigenschaften.
BewertungInformativ (Gewicht 0), falls gesetzt.
BehebungOptional je nach Anwendungsfall einsetzen.
Mixed Content #
Lädt eine HTTPS-Seite Ressourcen über http://, kann ein Angreifer sie manipulieren. Aktiver Mixed Content (Skripte/iframes/CSS) erlaubt die Übernahme der Seite, passiver Inhalt (Bilder) wird oft blockiert.
BewertungAktiver Mixed Content → fail; passiver → warn; keiner → pass. upgrade-insecure-requests zählt als Gegenmaßnahme. Gewicht 1–2.
BehebungAlle Ressourcen über HTTPS einbinden oder CSP upgrade-insecure-requests setzen.
Subresource Integrity (SRI) #
Cross-origin eingebundene Skripte/Styles (z. B. von CDNs) ohne integrity-Hash sind anfällig für Supply-Chain-Manipulation: Wird das CDN kompromittiert, läuft Angreifer-Code auf der Seite.
Bewertungpass, wenn cross-origin eingebundene Skripte ein integrity-Attribut tragen; sonst warn. Gewicht 1.
Behebungintegrity="sha384-…" crossorigin="anonymous" an cross-origin <script>/<link> ergänzen.
Integrity-Policy #
Erzwingt Subresource Integrity (SRI) für eingebundene Ressourcen – starker Supply-Chain-Schutz, der über das einzelne integrity-Attribut hinausgeht.
BewertungPositives Info-Signal (Gewicht 0) – kein Abzug bei Fehlen (neuer Header).
BehebungOptional Integrity-Policy: blocked-destinations=(script) setzen.
Cookie-Sicherheitsattribute #
Cookies ohne Secure können über HTTP abgefangen werden; ohne HttpOnly sind sie per JavaScript auslesbar (XSS); SameSite schützt vor CSRF.
Bewertungpass, wenn alle gesetzten Cookies Secure + HttpOnly tragen; sonst warn. Gewicht 1.
BehebungCookies mit Secure; HttpOnly; SameSite=Lax (oder Strict) ausliefern.
Cookie-Namenspräfixe (__Host-/__Secure-) #
Die Namenspräfixe __Host- und __Secure- (RFC 6265bis) lassen den Browser die Cookie-Integrität erzwingen: Ein __Secure--Cookie muss mit Secure gesetzt werden, ein __Host--Cookie zusätzlich mit Path=/ und ohne Domain-Attribut. Cookies, die dagegen verstoßen, werden vom Browser stillschweigend verworfen – die Anwendung erhält sie dann nie, was sich als mysteriöse Login-Schleifen äußert.
Bewertungwarn, wenn ein Cookie mit Präfix seine Voraussetzungen verletzt. Gewicht 1. Korrekt verwendete Präfixe sind schlicht Teil eines pass im Cookie-Check.
BehebungSecure setzen (und bei __Host-: Path=/, kein Domain=) – oder das Präfix gezielt nutzen: __Host-session=…; Secure; HttpOnly; SameSite=Lax; Path=/ ist die robusteste Form für Session-Cookies.
Cache-Control bei authentifizierten Antworten #
Authentifizierte Antworten (mit Session-/Auth-Cookie) sollten nicht in Proxys/Browsern gecacht werden – sonst könnten nachfolgende Nutzer die eingeloggten Inhalte anderer Personen sehen.
Bewertunginfo (Gewicht 0): wird NUR geprüft, wenn ein Session-/Auth-Cookie gesetzt ist und die Antwort nicht no-store/private ist (um False Positives auf öffentlichen Seiten zu vermeiden).
BehebungAuthentifizierte Antworten mit Cache-Control: no-store (oder private) ausliefern.
CORS (Access-Control-Allow-Origin) #
Eine fehlkonfigurierte CORS-Policy kann fremden Seiten erlauben, authentifizierte Antworten zu lesen. Ein reflektierter (oder *-)Origin in Kombination mit Access-Control-Allow-Credentials: true ist gefährlich.
Bewertungfail bei reflektiertem/*-Origin + Credentials (Auslesen authentifizierter Daten möglich); info bei * ohne Credentials (für öffentliche Assets meist unbedenklich). Wird nur geprüft, wenn ACAO gesetzt ist.
BehebungNie einen reflektierten Origin/* mit Allow-Credentials: true kombinieren; stattdessen eine strikte Origin-Allowlist verwenden.
X-Permitted-Cross-Domain-Policies #
Steuert, ob Adobe-Clients (Flash/Acrobat) domainübergreifend via crossdomain.xml zugreifen dürfen. Best Practice ist none. Die praktische Relevanz ist gering (Flash ist tot), aber Scanner wie securityheaders.com prüfen den Header.
Bewertungpass bei none; warn bei all; info bei jedem anderen Wert (z. B. master-only). Wird nur bewertet, wenn der Header gesetzt ist. Gewicht 0.
BehebungOptional X-Permitted-Cross-Domain-Policies: none setzen.
X-XSS-Protection (veraltet) #
Der frühere XSS-Auditor der Browser wurde entfernt und konnte selbst Sicherheitsprobleme verursachen (XS-Leaks). Der Header sollte nicht mehr aktiv verwendet werden.
Bewertunginfo (Gewicht 0), wenn auf 1/1; mode=block gesetzt – Empfehlung, ihn zu entfernen oder auf 0 zu setzen.
BehebungDen Header auf 0 setzen (oder entfernen) und stattdessen eine CSP verwenden.
HTTP Public Key Pinning (HPKP) #
HPKP sollte die Fehlausstellung von Zertifikaten verhindern, war aber so gefährlich (Risiko, sich dauerhaft selbst auszusperren), dass es aus allen Browsern entfernt wurde.
Bewertungwarn (Gewicht 1), wenn Public-Key-Pins(-Report-Only) gesetzt ist – der Header sollte entfernt werden.
BehebungDen HPKP-Header entfernen (stattdessen Certificate Transparency + CAA nutzen).
Expect-CT (veraltet) #
Der Expect-CT-Header wurde mit Chrome 107 entfernt – Certificate Transparency wird inzwischen automatisch durchgesetzt. Der Header ist überflüssig.
BewertungInformativ (Gewicht 0).
BehebungDen Expect-CT-Header entfernen.
Violation-/Fehler-Reporting #
Reporting liefert Berichte über CSP-/COOP-/Netzwerk-Verstöße. Es gibt zwei Generationen: Reporting-Endpoints (modern, bevorzugt) und das veraltete Report-To (von Chrome als deprecated eingestuft). Wichtig: NEL (Network Error Logging) funktioniert NUR mit Report-To, nicht mit Reporting-Endpoints.
Bewertunginfo (Gewicht 0): unterscheidet modern/legacy/NEL. warn, wenn NEL auf eine Report-To-Gruppe verweist, die nicht definiert ist (Reports gehen stillschweigend verloren). Nur veraltetes Report-To → Hinweis auf Migration.
BehebungReporting-Endpoints setzen; für NEL zusätzlich eine passende Report-To-Gruppe definieren.
Technologie-Preisgabe (Server / X-Powered-By) #
Header wie Server: nginx/1.26.3 oder X-Powered-By: PHP/8.2 verraten den Software-Stack. Eine Versionsnummer erlaubt es einem Angreifer, bekannte CVEs direkt dem exakten Build zuzuordnen – genau das ist entscheidend und führt zur Abwertung. Ein bloßer Produktname (Server: nginx, AmazonS3, cloudflare, Apache) sagt nur, WAS läuft, nicht in welcher Version; er lässt sich keinem konkreten CVE zuordnen und wird rein informativ behandelt (keine Abwertung). Eine „Version“ bedeutet eine gepunktete Dezimalangabe (z. B. /1.26.3, 4.0.30319); ein Produktname, der lediglich eine Ziffer enthält (AmazonS3, CDN-Node-IDs), ist keine Version. Banner vollständig zu verbergen ist Hygiene (minimale Preisgabe), aber kein Ersatz für Patching.
Bewertunggood, wenn keine Technologie-Header gesendet werden; info bei reinen Produktnamen, auch wenn der Name eine Ziffer enthält wie AmazonS3 (Gewicht 0, keine Abwertung); warn nur, wenn eine tatsächliche Versionsnummer (gepunktete Dezimalangabe) preisgegeben wird (Gewicht 1). Geprüft werden: Server, X-Powered-By, X-AspNet-Version, X-AspNetMvc-Version, X-Generator.
Behebungnginx: server_tokens off (verbirgt die Version) oder den Header mit dem headers-more-Modul komplett entfernen (more_clear_headers Server); Express: app.disable("x-powered-by"); PHP: expose_php = Off.
security.txt (RFC 9116) #
Eine /.well-known/security.txt stellt Kontaktkanäle für Sicherheitsmeldungen bereit und erleichtert die verantwortungsvolle Offenlegung (Responsible Disclosure) von Schwachstellen. Die Datei wird gegen die MUSS-/SOLL-Anforderungen von RFC 9116 validiert, so wie es der sectxt-Validator von internet.nl macht: Pflichtfeld Contact (als URI – eine nackte E-Mail-Adresse ohne mailto: ist ungültig, §2.5.3), genau ein Expires im RFC-3339-Format, das nicht in der Vergangenheit liegt (§2.5.5), text/plain mit UTF-8 (§3), https:// für alle Web-URIs, gültige Feldsyntax, höchstens ein Preferred-Languages mit gültigen Kürzeln, der Pflicht-Ablageort /.well-known/ (§3) und – falls Canonical vorhanden ist – dass die Abruf-URI dort gelistet ist (§2.5.2, sonst sollte der Datei nicht vertraut werden). SOLL-Anforderungen (Expires unter einem Jahr, OpenPGP-Signatur, Encryption-Schlüssel bei E-Mail-Kontakt) werden als Hinweise ausgewiesen; die Signatur wird strukturell, nicht kryptografisch geprüft.
Bewertunggood, wenn vorhanden und die Validierung keine Fehler meldet (offene Empfehlungen werden als Hinweise gelistet); warn, sobald mindestens eine Beanstandung der Fehler-Klasse vorliegt – dieselbe Schwere-Einteilung wie bei internet.nl; info, wenn nicht vorhanden. Gewicht 0.
BehebungEine Datei unter /.well-known/security.txt mit Contact: (mailto:-/tel:-/https:-URI) und Expires: (RFC 3339, weniger als ein Jahr in der Zukunft) bereitstellen, ausgeliefert als text/plain; charset=utf-8; bei Nutzung von Canonical die exakte Abruf-URI dort listen. Gegenprüfung z. B. mit dem security.txt-Check von internet.nl.