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: September 2026 · 34 Checks dokumentiert
Website konfiguriert (A/AAAA-Records) #
Die Module Website und HTTP-Security-Header prüfen eine laufende Website. Hat weder die Domain selbst noch www A- oder AAAA-Records, gibt es keine Website, zu der eine Verbindung aufgebaut werden könnte – ein völlig normales Setup für Domains, die nur für E-Mail genutzt werden.
BewertungErscheint nur, wenn die Domain selbst existiert (NOERROR), aber keine A/AAAA-Records hat, www ebenfalls keine hat (eindeutige NOERROR/NXDOMAIN-Antworten) und auf keinem der beiden Namen ein CNAME konfiguriert ist: skip; das Modul wird als nicht anwendbar gemeldet, statt mit F benotet zu werden. Alles andere – ein DNS-Fehler (z. B. eine kaputte DNSSEC-Kette), eine nicht existierende Domain oder ein ins Leere zeigender CNAME – lässt die regulären Checks laufen, damit eine defekte Website weiterhin als nicht erreichbar erscheint. Vor der Behauptung wird der Name zusätzlich nach einem HTTPS-Record gefragt: RFC 9460 erlaubt es, einen Dienst über einen AliasMode-Record ganz ohne eigene Adressrecords zu erreichen. Wird einer gefunden, meldet das Modul skip und nicht gemessen und wird NICHT als nicht anwendbar geführt – die Seite existiert, sie wurde hier nur nicht geprüft; antwortet diese Abfrage nicht schlüssig, wird in keine Richtung etwas behauptet.
BehebungNichts zu tun, wenn die Domain bewusst nur für E-Mail genutzt wird. Soll eine Website existieren, A/AAAA-Records für die Domain oder www anlegen und den Scan erneut ausführen.
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. Ein vierter Fall wird getrennt benannt: Der Server antwortet, aber der HTTP-Client dieses Scanners verwirft die Antwort als fehlerhaft. Node tut das für eine komplette Antwort, sobald ein Header-Wert ein Steuerzeichen enthält. RFC 9110 §5.5 nennt solche Werte ungültig, lässt dem Empfänger aber die Wahl — für andere Steuerzeichen als CR, LF und NUL heißt es dort, Empfänger DÜRFEN sie behalten —, und Chromium und Gecko nutzen genau das – der Befund sagt dann, was auf unserer Seite passiert ist, statt die Seite für nicht erreichbar zu erklären.
BewertungErscheint nur, wenn der Seitenaufruf scheitert: skip; das Modul wird als nicht benotbar gemeldet, statt bei fehlenden Daten mit F benotet zu werden. Hat weder die Domain noch www überhaupt A/AAAA-Records, erscheint stattdessen der präzisere Eintrag „Website konfiguriert (A/AAAA-Records)“.
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. Ebenfalls info, wenn die Weiterleitung innerhalb derselben registrierbaren Domain bleibt, aber auf einem anderen Host landet (der häufige Fall apex → www): Alle Header-Befunde darunter beschreiben dann diesen Host. Auch info, wenn die Kette nach dem fünften Hop noch weiterleitet – die benoteten Header gehören dann zu einer Zwischenantwort, was eine Grenze dieses Scans ist. Gar nichts angezeigt wird nur, wenn die Seite per HTTPS auf DEMSELBEN Host 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 bei jedem späteren Besuch. Den ersten Kontakt mit einem Host, den der Browser noch nicht kennt, kann es nicht schützen: Bevor eine HTTPS-Antwort mit dem Header gesehen wurde — entweder vom Host selbst oder von einer Elterndomain mit includeSubDomains, was eine Subdomain schon bei ihrer allerersten Anfrage abdeckt (RFC 6797 §8.3 Schritt 5) —, kennt der Browser die Regel nicht; genau diese Lücke schließt die Preload-Liste.
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. Zweiter Sonderfall: ein HSTS-Header auf einer Antwort, die auf unverschlüsseltem http:// endete → fail, denn Browser verarbeiten den Header nur über eine gesicherte Verbindung (RFC 6797 §8.1) – er bleibt dort wirkungslos, gleich welches max-age er nennt. Gewicht 2.
BehebungDen Header setzen: Strict-Transport-Security: max-age=63072000; includeSubDomains. preload nur ergänzen, wenn die Domain bewusst fest in die Browser eingetragen werden soll und HTTPS auf jeder Subdomain geprüft ist – die Direktive ist eine Einreichungs-Zustimmung, und während der Weg auf die Liste leicht ist, dauert der Weg herunter Monate an Browser-Releases; siehe den Eintrag HSTS-Preload.
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, wenn der Schutz von einem Vorfahren-Eintrag kommt (z. B. eine preloadete TLD mit includeSubDomains – der eigene Header des Hosts kann an diesem Eintrag nichts ändern), 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 – und nur dann, wenn der gelistete Host auch der Host ist, dessen Header gelesen wurde: Nach einer Weiterleitung auf einen anderen Host gehört der Header diesem Host, der Befund fällt deshalb auf info (Gewicht 0) und benennt die Lücke, statt anzuklagen. Antwortet die Status-API von hstspreload.org nicht, sagt der Befund, dass der Listenstatus nicht ermittelt werden konnte, statt zu behaupten, die Domain sei nicht preloaded.
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. Die Kriterien werden nicht nacherzählt, sondern verglichen: Ein wörtlicher Auszug des internet.nl-Checkers läuft neben unserem über dieselben Policies, sodass jeder Unterschied eine begründete Entscheidung ist und keine Drift. Zwei davon sind bewusst und zu Ihren Gunsten — ein Wildcard-Host wird nur mit Label-Grenze akzeptiert, und ein frame-src, das auf ein default-src * zurückfällt, gilt nicht als eingeschränkt.
Bewertungpass bei einer starken (Nonce/Hash) CSP oder einer Allowlist ohne unsichere Quellen; warn bei unsafe-inline/Wildcards ohne Nonce, bei reinem Report-Only, wenn überhaupt keine skriptbeschränkende Direktive ausgeliefert wird (script-src-elem → script-src → default-src fehlen alle – Skripte sind dann unbeschränkt), und wenn die CSP nur per <meta>-Tag ankommt (frame-ancestors, sandbox und Reporting werden dort ignoriert); fail nur, wenn in keiner Form eine Policy ausgeliefert wird. 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.
BewertungWird nur gemeldet, wenn die Policy Trusted Types überhaupt erwähnt. good (Gewicht 0), wenn require-trusted-types-for 'script' die Durchsetzung tatsächlich einschaltet; info, wenn nur eine trusted-types-Direktive erlaubte Policies benennt – das deklariert Namen, erzwingt aber nichts, die DOM-Injection-Sinks nehmen weiterhin einfache Strings an. 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.
Bewertunggood (grüner Haken, nicht benotet) bei gültigem report-to; warn, wenn report-to auf einen nicht definierten Endpunkt zeigt; info, wenn nur das veraltete report-uri verwendet wird – es wird für sich weiterhin ausgewertet, diese Reports kommen also an. 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, und CSP frame-ancestors gewinnt immer: Sobald irgendeine durchgesetzte Policy es trägt, ignorieren Browser X-Frame-Options vollständig (HTML-Standard §7.7) – auch ein DENY. pass bei frame-ancestors none/self/Host-Allowlist oder, wenn kein frame-ancestors ausgeliefert wird, bei X-Frame-Options: DENY/SAMEORIGIN; pass auch, wenn mehrere widersprüchliche XFO-Werte ankommen und mindestens einer davon DENY, SAMEORIGIN oder ALLOWALL ist, denn Browser blockieren die Seite dann (fail-closed) – mit dem Hinweis, die Konfiguration zu bereinigen. Ein Satz aus lauter UNGÜLTIGEN Werten ist nicht dieser Fall: Der HTML-Standard §7.7 behandelt ihn wie einen fehlenden Header. warn bei frame-ancestors */Scheme-Wildcard. fail, wenn beides fehlt, und wenn der einzige XFO-Wert ein anderer ist (ALLOW-FROM, ALLOWALL, ein Tippfehler): Dann ist das Einbetten von überall erlaubt, dieselbe Blöße wie gar kein Header. 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. Ohne Header entsteht kein Leck: Jede aktuelle Engine verwendet standardmäßig strict-origin-when-cross-origin (Chrome 85, Firefox 87, Safari 15), Cross-Origin-Anfragen tragen also nur den Origin. Ein expliziter Header bewirkt, dass das Verhalten nicht mehr am Browser hängt. Einige Werte sind tatsächlich unsicher: unsafe-url sendet immer die vollständige URL, origin-when-cross-origin gibt den Pfad innerhalb des Origins preis, und no-referrer-when-downgrade sendet die vollständige URL – inklusive Pfad und Query – an jedes gleich oder besser gesicherte Ziel, auch an fremde HTTPS-Seiten; nur bei einem HTTPS→HTTP-Downgrade unterbleibt der Referrer, dem einen Fall, den sein Name beschreibt.
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, und warn bei fehlendem Header – jede aktuelle Engine fällt dann auf strict-origin-when-cross-origin zurück (der Fetch-Standardwert seit der Spezifikationsänderung vom November 2020), es leckt also keine vollständige URL; was fehlt, ist die ausdrückliche, engine-unabhängige Härtung. 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. Zur Reichweite: Nur Chromium wertet diesen Header aus – er härtet also für einen Teil der Besucher, nicht für alle. Firefox liest ihn in seinem Produktivcode nirgends, und WebKit setzt allein das allow-Attribut am iframe um, nicht die von diesem Header deklarierte Policy (der Quelltext sagt es wörtlich: "Declared policy is not implemented yet", geprüft 2026-08). Der Header selbst ist keine Herstellererweiterung: Er ist ein W3C Working Draft (Permissions Policy, Fassung vom 18. Juni 2026). Sein Fehlen ist auch keine offene Tür: Jedes Feature hat eine Standard-Allowlist, und bei den mächtigen ist das self. Allowlist-Syntax: () = aus, self = nur eigene Domain, * = überall (Risiko), (self "https://…") = Allowlist. Auf die Anführungszeichen achten: self ist ein Token und muss ohne sie stehen – ("self") schaltet das Feature komplett ab, 'self' (CSP-Schreibweise) ist überhaupt kein gültiges Structured Field, der ganze Header parst damit nicht – der Browser verwirft ihn samt jeder anderen Direktive darin. Ein Feature-Name, den der Browser nicht KENNT, ist ein anderer Fall, und der Unterschied entscheidet, wie viel übrig bleibt: Ein unbekanntes Member ist trotzdem ein wohlgeformter Structured-Field-Eintrag, der Browser behält also den Rest des Headers und schreibt nur Unrecognized feature: 'x' in die Konsole. In Chrome 152 über vier Zustände gemessen, mit einer Kontrolle, die den erlaubenden Ausgang überhaupt sehen kann: ohne Header ist camera erlaubt, mit camera=() gesperrt, mit camera=() plus einem unbekannten Member weiterhin gesperrt, und mit dem fehlerhaften camera =() wieder erlaubt. Eine Konsolenwarnung dieser Art heißt also, dass EIN Member wirkungslos ist; ein Parse-Fehler heißt, dass keines gilt. Wirkungslos ist nicht dasselbe wie harmlos: Ist der unbekannte Name ein TIPPFEHLER (camrea=() statt camera=()), fehlt die gewollte Einschränkung schlicht, während der Rest des Headers normal parst – gemessen sperrt camrea=(), microphone=() das Mikrofon und lässt die Kamera auf ihrem Standard. Die Warnung ist also lesenswert: Sie heißt entweder, dass der Browser das Feature nicht kennt, oder dass der Name falsch geschrieben ist – unterscheiden kann das nur der Betreiber. Und ob ein Name erkannt wird, ist eine Eigenschaft des BUILDS, nicht der Spezifikation: bluetooth=() steht in der Spezifikation und wird von einem Chrome, dessen Web Bluetooth herauskompiliert ist, als unbekannt gemeldet (gemessen, Chrome 152 unter Linux) – die Warnung allein macht den Header also nicht falsch, sie heißt nur, dass der Browser dieses einen Besuchers mit diesem einen Member nichts anfangen kann.
Bewertungpass, wenn die Kern-Features (camera/microphone/geolocation/payment/usb) deaktiviert sind; warn bei Wildcard * auf einem Kern-Feature, fehlendem Header, leeren/permissiven Werten, veralteter Feature-Policy-Syntax, einem Header, der nicht als Structured-Field-Dictionary (RFC 9651) parst – dann verwerfen Browser den GANZEN Header und es ist gar nichts eingeschränkt; übliche Ursache ist ein Leerzeichen neben dem =, wie in camera =() oder camera= () –, einem weiteren Hochrisiko-Feature (display-capture, serial, hid, bluetooth …), das per * freigegeben ist, oder einem gequoteten self – es ist ein Token und muss ohne Anführungszeichen stehen, ("self") schaltet das Feature komplett ab und 'self' ist überhaupt kein gültiges Structured Field, der Browser verwirft deshalb den ganzen Header. Ein Hochrisiko-Feature, das lediglich nicht erwähnt wird, ist meist nicht die größte Lücke: Seine Standard-Allowlist ist self, ein Cross-Origin-Frame bekommt es also nur, wenn die Seite es selbst per allow-Attribut am iframe delegiert – und genau diese Delegation würde ein ausdrückliches camera=() weiterhin sperren. 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, same-origin, same-origin-allow-popups und noopener-allow-popups dagegen schon – letzteres kappt die Opener-Beziehung zu selbst geöffneten Fenstern, lässt Popups aber nutzbar. 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. Alle drei Header sind etabliert: COOP und COEP laufen seit Chrome 83, Firefox 79 und Safari 15.2, CORP seit Chrome 73, Firefox 74 und Safari 12, und das MDN HTTP Observatory belohnt jeden von ihnen (+10 Punkte, −5 bei ungültigem Wert). Wir benoten sie trotzdem nicht, denn COOP same-origin zu verlangen kann auf gewöhnlichen Seiten OAuth-/Payment-Popups brechen: Cross-Origin-Isolation ist eine bewusste Architekturentscheidung, keine Grundausstattung. Ein schützender COOP-Wert (same-origin, same-origin-allow-popups, noopener-allow-popups) erhält einen grünen Haken (good) – aber nur auf einer HTTPS-Seite, denn außerhalb sicherer Kontexte ignorieren Browser COOP (der HTML-Standard §7.1.3.1 gibt für einen nicht sicheren Kontext die Standard-Policy zurück, und Gecko setzt genau das um). noopener-allow-popups ist der jüngste der drei und gilt nicht überall: Der COOP-Parser von Firefox kennt nur same-origin und same-origin-allow-popups (2026-08 mit Positivkontrolle geprüft), dort fällt der Wert also auf unsafe-none durch und schützt nichts. unsafe-none, ein fehlender Header, ein unbekannter Wert und ein doppelt gesendeter Header (Browser lesen ihn als einzelnes Structured-Field-Item, dieser Parse scheitert, und es gilt unsafe-none) sind neutrales info. Alle Werte werden case-sensitiv verglichen. 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, ihren Agent-Cluster nach Origin statt nach Site zu schlüsseln. Die beobachtbare Wirkung: document.domain lockert die Same-Origin-Beschränkung nicht mehr, und WebAssembly-Module lassen sich nicht mehr an same-site cross-origin Dokumente senden. Ein Browser darf der Bitte mit einem eigenen Prozess nachkommen, muss es aber nicht – MDN sagt ausdrücklich, dies sei „nicht als Sicherheitsfunktion zu betrachten“, und der Schutz vor Spectre-artigen Seitenkanalangriffen kommt von der Cross-Origin-Isolation (COOP+COEP), nicht von diesem Header. Jeder andere Wert als ?1 – insbesondere ?0 – ist die gegenteilige Bitte.
BewertungDer Wert zählt, nicht das Vorhandensein: good (Gewicht 0) bei ?1; info bei ?0, das ausdrücklich AUF origin-basierte Agent-Cluster VERZICHTET (Chrome schlüsselt seit Version 119 standardmäßig nach Origin – bis einschließlich 118 steht der Compile-Default auf aus, und was in 115 geschah, war ein Feldversuch hinter einem Flag; an Chrome 152 gemessen meldet eine Seite ganz ohne Header originAgentCluster === true –, ?0 bittet also um die Rückkehr zum Site-Keying und hält die alte document.domain-Relaxation nutzbar – ein legitimer Kompatibilitätsschalter, aber das Gegenteil einer Härtung); info bei jedem anderen Wert, den Browser ignorieren. Nie benotet: Der HTML-Standard sagt, dies sei keine Sicherheitsfunktion.
BehebungOptional Origin-Agent-Cluster: ?1 setzen.
Document-Policy #
Document-Policy konfiguriert dokumentweites Verhalten – ein Geschwister der Permissions-Policy, aber für Dokumenteigenschaften statt für Gerätefunktionen. Es ist ein in Chromium inkubierter Vorschlag, der stehen geblieben ist: Die WICG-Spezifikation hat seit März 2022 überhaupt keinen Commit mehr erhalten (geprüft 2026-08). Safari setzt nichts davon um: WebKit — anders als die TLS-Engine öffentlich — kennt weder den Header noch einen der ausgelieferten Punkte (Quelltext geprüft 2026-08), und WebKits eigene Testerwartung für force-load-at-top steht auf FAIL. Firefox setzt genau einen Punkt um: Es liest den Header, parst ihn als Structured-Field-Dictionary und ehrt force-load-at-top für seine Text-Fragmente – sonst nichts. Ausgeliefert wurde nur eine Handvoll Punkte – force-load-at-top, expect-no-linked-resources und js-profiling, das die JS-Self-Profiling-API freischaltet –, während die oft zitierten Bild-Policies (oversized-images, unoptimized-lossy-images) nie über das Flag-Stadium hinauskamen.
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) würde die Übernahme der Seite erlauben und wird deshalb von jedem aktuellen Browser hart blockiert; passiver Inhalt (Bilder, Medien) wird nach Möglichkeit auf HTTPS angehoben und andernfalls blockiert. Der Befund betrifft also weniger das, was noch lädt, als eine Konfiguration, die darauf angewiesen ist, dass der Browser hinter ihr aufräumt.
BewertungAktiver Mixed Content → fail; passiver → warn; keiner → pass; info („nicht ermittelt“), wenn die Seite unser 256-KB-Leselimit überschritten hat und abgeschnitten wurde – eine gefundene Ressource zählt trotzdem, denn Vorhandensein braucht keine Vollständigkeit, eine Entwarnung schon. Gezählt werden nur echte Elemente: Markup in einem Kommentar oder im Rumpf eines <script>- oder <style>-Blocks ist für den Browser Text und löst keinen Abruf aus, wird hier also ebenfalls übersprungen. Kommentar-Enden folgen dem HTML-Standard, --!> eingeschlossen; nur ein UNTERMINIERTES <!-- wird bewusst überlesen, weil sonst der ganze Rest der Seite als Kommentar gälte und jeden späteren Befund darauf verdecken würde. Markup in einem <template> wird MITGEZÄHLT – es lädt nichts, solange kein Skript es klont, aber genau dafür sind Templates da, und nach dem Klon ist der Abruf echt. Attributwerte werden so gelesen, wie ein Browser sie liest, mit aufgelösten HTML-Zeichenreferenzen: ein als http://… geschriebenes src gilt hier nicht als harmlos. upgrade-insecure-requests zählt als Gegenmaßnahme und wird sowohl aus dem CSP-Header als auch aus einem <meta http-equiv>-Tag gelesen, das diese Direktive tatsächlich durchsetzt. 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 jedes cross-origin eingebundene Skript ein integrity-Attribut trägt; warn, sobald eines es nicht tut; info („nicht ermittelt“), wenn die Seite unser 256-KB-Leselimit überschritten hat – ein gefundenes Skript ohne integrity zählt trotzdem, eine Entwarnung braucht die vollständige Seite. Geprüft wird nur, ob das Attribut vorhanden ist, nicht ob sein Hash stimmt oder sein Algorithmus noch akzeptabel ist; auskommentierte Tags werden ignoriert (mit denselben Kommentar-Regeln wie oben), ebenso Markup, das nur im Rumpf eines <script>- oder <style>-Blocks steht – der Parser liest das als Rohtext und nicht als Markup. Das gilt für den HTML-Namensraum: Innerhalb von <svg> oder <math> sind dieselben Tags kein Rohtext, Markup darin wird normal geparst — dieser Scanner überspringt es dort ebenfalls, was nur bedeuten kann, dass er weniger meldet, nie mehr. Gewicht 1.
Behebungintegrity="sha384-…" crossorigin="anonymous" an cross-origin <script>/<link> ergänzen.
Integrity-Policy #
Integrity-Policy erzwingt Subresource Integrity für die gelisteten Ziele: Ressourcen ohne integrity-Metadaten werden blockiert – Supply-Chain-Schutz, der über das einzelne integrity-Attribut hinausgeht. Integrity-Policy-Report-Only meldet Verstöße, ohne etwas zu blockieren: ein Probelauf, kein Schutz.
Bewertunggood beim durchsetzenden Header, info bei Report-Only – in beiden Fällen Gewicht 0 und kein Abzug bei Fehlen. Der Header ist jung (Chrome 138, Firefox 145, Safari 26), und ihn durchzusetzen verlangt, dass jede eingebundene Ressource integrity-Metadaten trägt.
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; warn, wenn eines von beiden fehlt; fail, wenn ein Cookie SameSite=None ohne Secure verwendet – kaputt ist es in jedem Fall: Chrome und Firefox lehnen es rundheraus ab (RFC 6265bis §5.7 Schritt 19), während Safari 26.6 es weiterhin annimmt und dann ungeschützt über HTTP schickt (web-platform-tests, ausgerichteter Stable-Lauf 2026-08). Ein Cookie ohne WIRKSAMEN SameSite-Wert wird im Detail benannt (Chromium behandelt es dann als Lax, Firefox wendet diesen Standard nicht an – geprüft 2026-08, und dort ist es eine Einstellung und keine feste Regel), ändert das Urteil aber nicht – wirksam heißt: Attribut vorhanden UND sein Wert einer von Strict/Lax/None, denn alles andere fällt auf denselben Standard zurück wie ein fehlendes Attribut. Attributnamen und -werte werden so gelesen, wie ein Browser sie liest (RFC 6265bis §5.6): Es werden nur Leerzeichen und Tabulatoren entfernt, ein Secure mit vorangestelltem geschützten Leerzeichen ist also ein unbekanntes Attribut und zählt nicht. 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 verworfen, ohne dass der Server ein Signal bekommt – die Anwendung erhält sie dann nie, was sich als mysteriöse Login-Schleifen äußert. Firefox protokolliert es immerhin in der Web-Konsole („has been rejected for invalid prefix“) — dort zuerst nachsehen, bevor man serverseitig sucht.
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, die RFC 6265bis standardisiert. Chrome und Firefox erzwingen zusätzlich ein nicht standardisiertes Präfix __Host-Http-, das auch HttpOnly festnagelt; es steht weder in draft-22 noch in der Editor-Kopie, und Safari 26.6 setzt es nur teilweise um (5 von 7 web-platform-tests, gegenüber 7 von 7 bei beiden anderen).
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 die LETZTE Antwort – die, deren Cache-Control-Header gelesen wird – selbst ein Session-/Auth-Cookie setzt und nicht no-store/private ist. Ein Cookie, das früher in der Redirect-Kette gesetzt wurde, zählt nicht: Cookie und Header müssen dieselbe Antwort beschreiben, sonst erzeugt ein Login-Redirect einen Befund über eine Seite, die das Cookie nie gesetzt hat.
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. Gefährlich ist die Kombination aus einem reflektierten Origin – oder dem wörtlichen null – mit Access-Control-Allow-Credentials: true. Ein blankes * gehört nicht dazu: Browser akzeptieren die Wildcard für eine Anfrage mit Credentials nie, auf diesem Weg lässt sich also nichts auslesen.
Bewertungfail (Gewicht 2) nur bei null + Credentials – ein Dokument in einem iframe, dessen sandbox kein allow-same-origin enthält, hat einen opaken Origin und sendet damit genau den Origin null, authentifizierte Antworten werden dann tatsächlich herausgegeben. warn (Gewicht 1) bei * + Credentials (widersprüchliche Konfiguration: Browser blockieren die Kombination, es leckt also nichts, aber eine der beiden Einstellungen ist wirkungslos), bei festem Origin + Credentials (an sich in Ordnung – kritisch nur, wenn der Server beliebige Origin-Werte reflektiert, was eine passive Header-Prüfung nicht entscheiden kann) und bei ungültiger ACAO-Syntax wie mehreren Origins oder einer Wildcard-Subdomain (passt zu gar keinem Origin). info bei * ohne Credentials – die vorgesehene Form für öffentliche Ressourcen. 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 das OWASP Secure Headers Project führt ihn weiterhin unter den zu setzenden Headern, mit none als empfohlenem Wert.
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, doch das Risiko, sich dauerhaft selbst auszusperren, war so hoch, dass jeder Browser es entfernt hat (Chrome in 72, Firefox in 72–78; Safari und Edge haben es nie umgesetzt). Weil nichts mehr gepinnt wird, schützt der Header heute nichts und gefährdet nichts – er ist tote Konfiguration. Gegen Fehlausstellung wirken heute stattdessen zwei getrennte Ebenen: CAA schränkt ein, welche CA überhaupt ausstellen darf (geprüft von der CA, RFC 8659 §4), und Certificate Transparency macht ein ausgestelltes Zertifikat öffentlich auffindbar. Keines von beiden ist eine vom Browser durchgesetzte Bindung, also auch kein Ersatz. Zu beachten: RFC 7469 selbst ist weiterhin Proposed Standard – veraltet ist die Browser-Unterstützung, nicht die Spezifikation.
Bewertunginfo (Gewicht 0), wenn Public-Key-Pins(-Report-Only) gesetzt ist. Da kein Browser HPKP mehr auswertet, kann der Header auch keinen Schaden anrichten – es gibt nichts mehr abzuziehen. Ihn als tote Konfiguration zu entfernen, lohnt trotzdem.
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 (aus der Reporting-Spezifikation entfernt und bei MDN als deprecated/non-standard geführt, aber weiterhin ausgewertet – Chrome 70+, Firefox 149+, von Safari nicht unterstützt). Wichtig: NEL (Network Error Logging) funktioniert NUR mit Report-To, nicht mit Reporting-Endpoints.
Bewertunggood (Gewicht 0), wenn ein Reporting-Mechanismus konfiguriert ist; info, wenn nur das alte Report-To verwendet wird – ein Migrationshinweis, kein Mangel; warn, wenn NEL auf eine Report-To-Gruppe verweist, die nicht definiert ist (Reports gehen stillschweigend verloren), und warn, wenn der Header Reporting-Endpoints kein gültiges Structured Field (RFC 9651) ist: Browser verwerfen ihn dann vollständig, es existiert keine Endpoint-Gruppe; übliche Ursache ist ein Leerzeichen um das =. Lässt sich der Report-To-Header nicht parsen, wird der Gruppenabgleich übersprungen statt geraten. Zwei weitere Formen sind direkt gegen Chrome 152 gemessen und nicht aus der Grammatik hergeleitet: Ein Member, dessen Wert keine Zeichenkette in Anführungszeichen ist (good="https://…", bad=sometoken), lässt Chromium das ganze Feld verwerfen – es gilt hier deshalb als nicht auswertbar, obwohl der Spezifikationstext nur das Überspringen dieses einen Members vorsieht. Das ist eine bewusste Entscheidung gegen die beiden anderen Engines und keine Lücke: Alle drei lesen diesen Header (Chromium seit 96, Safari seit 16.4, Firefox seit 149 im Rapid-Release-Kanal – ESR 140 liefert die Reporting-API weiterhin abgeschaltet aus), und bei genau dieser Form folgen Firefox und WebKit dem §3.3 und überspringen nur das fehlerhafte Member, ihre übrigen Endpunkte arbeiten also weiter. Dieser Bericht folgt der strengsten der drei Lesarten, weil die Fehlerkosten ungleich sind: einen funktionierenden Header als kaputt zu melden kostet einen Hinweis, einer Gruppe zu vertrauen, die Chrome nie registriert hat, wäre eine falsche Entwarnung. Firefox und Safari sind dafür im Quelltext gelesen, nicht gefahren; und ein Member, dessen URL nicht *potentially trustworthy* ist — in der Praxis: nicht https:// —, fällt für sich weg, während der Rest des Headers weiterarbeitet (W3C Reporting API §3.2 – Browser ignorieren einen unsicheren Endpunkt). Das ist warn und nennt die Gruppe, denn dorthin gerichtete Meldungen gehen still verloren.
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. Über die strukturellen Checks hinaus wird die OpenPGP-Ebene kryptografisch geprüft (RFC 9580): Der unter Encryption veröffentlichte Schlüsselblock wird abgerufen und bewertet (verwertbarer öffentlicher Schlüssel, RSA-Schlüsselgröße, ROCA-/Fermat-Faktorisierbarkeit bis 4096 Bit – darüber meldet der Bericht, dass die Prüfung nicht lief, statt einen sauberen Schlüssel auszuweisen –, kein geleakter privater Schlüsselblock), und die Cleartext-Signatur wird gegen die Schlüssel dieses veröffentlichten Blocks verifiziert. Ob ein Schlüssel innerhalb des Blocks wirklich ein Unterschlüssel des Hauptschlüssels ist, wird geprüft: Die 0x18-Bindungssignatur muss gegen den Hauptschlüssel halten, und bei einem SIGNATUR-Unterschlüssel zusätzlich die eingebettete 0x19-Rücksignatur gegen den Unterschlüssel (RFC 9580 §5.2.4, §5.2.3.34) – ohne die könnte jeder einen fremden Signaturschlüssel in sein eigenes Zertifikat binden. Erst dann nennt der Bericht den Unterzeichner einen Unterschlüssel des veröffentlichten Schlüssels; ein Schlüsselpaket ohne gültige Bindung wird als das benannt, was es ist – ein Schlüssel, der im ausgelieferten Block liegt, ohne zu diesem Zertifikat zu gehören. Für eine User ID gilt derselbe Maßstab: Der Bericht sagt erst dann, dass ein Block eine Adresse zertifiziert, wenn die 0x10-0x13-Selbstzertifizierung dieser User ID gegen den Hauptschlüssel verifiziert und kein neuerer 0x30-Widerruf sie überholt (RFC 9580 §5.2.4, §5.2.1) – bei einem Block aus einem Verzeichnis Dritter ist die Adresse sonst nur Text in einem Paket, das niemand signiert hat. Ob ein Signatur-Unterschlüssel noch gilt, wird ebenfalls aus dem Zertifikat gelesen: ein 0x28-Subkey-Widerruf und die beiden Laufzeiten aus §5.2.3.13 und §5.2.3.18. Ein widerrufener oder abgelaufener Unterschlüssel verifiziert rechnerisch weiterhin – der Bericht benennt das, statt ein bloßes „gültig“ zu drucken. Beanstandet werden eine Signatur, die nicht zum ausgelieferten Inhalt passt, ein verbotener Hash (MD5/SHA-1/RIPEMD-160) oder spoofbare Armor-Header; eine Signatur von einem anderen als dem veröffentlichten Schlüssel wird ausgewiesen. Nennt die Datei einen mailto:-Kontakt, wird diese Adresse zusätzlich im Web Key Directory ihrer eigenen Domain nachgeschlagen: Ein Schlüssel, der nur aus der Datei verlinkt, aber nicht per WKD auffindbar ist, wird vom Mailprogramm eines Melders nicht automatisch gefunden.
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 der Pflichtpfad geantwortet hat und keine verwertbare Datei gefunden wurde („fehlt“), und ebenfalls info – aber als „nicht ermittelt“ formuliert –, wenn unser eigener Abruf von /.well-known/security.txt gescheitert ist oder wenn das Zeitbudget des Moduls aufgebraucht war, bevor er überhaupt gesendet werden konnte, denn weder ein Timeout noch ein Budget auf unserer Seite ist eine Aussage über die Domain. Signatur- und Schlüsselprobleme fallen in dieselben Klassen: Fehler bei ungültiger Signatur, verbotenem Hash, faktorisierbarem oder geleaktem Schlüssel – Hinweise bei nicht abrufbarem Encryption-Schlüssel oder Signatur von einem anderen Schlüssel. 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. Die Datei als OpenPGP-Cleartext-Signatur mit dem unter Encryption veröffentlichten Schlüssel signieren (SHA-256 oder stärker) und nach jeder Inhaltsänderung neu signieren. Gegenprüfung z. B. mit dem Website-Test von internet.nl, der dieselbe sectxt-Validierung fährt.