Das Schloss zeigt nicht, ob Ihr Zertifikat morgen erneuert wird oder ob eine fremde Website Ihre Seite einbetten kann. TLS und HTTP-Antwortrichtlinien lösen unterschiedliche Probleme. Eine gemeinsame Prüfung macht dringende Erreichbarkeitsprobleme und fehlende Schutzschichten sichtbar.
Sitelemetry erfasst im TLS-Modul Vertrauen, Gültigkeit und ausgehandeltes Protokoll. Das Header-Modul untersucht eine echte Antwort und speichert finale URL, Status und Header. Diese Beobachtungen beginnen die Behebung; sie bedeuten keinen vollständigen Penetrationstest der Anwendung.
Umfang dieser Prüfung
Was messbar ist
- TLS-Vertrauen, Zertifikatsdaten, Aussteller und ausgehandeltes Protokoll der getesteten Verbindung.
- Beobachtete HSTS-, CSP-, Frame-, Inhaltstyp- und Referrer-Kontrollen sowie ausgewählte Offenlegungs- und CORS-Signale.
- Sicherheitsattribute tatsächlich zurückgegebener Cookies und unterstützte erfolgreiche Prüfungen.
Was sie nicht belegt
- Eine ausgehandelte TLS-Version ist keine vollständige Liste unterstützter Protokolle und Cipher.
- Eine öffentliche Antwort zeigt nicht sämtliche authentifizierten Cookies und routenspezifischen Richtlinien.
- Verhindern TLS oder Netzwerk eine Antwort, bleiben Header ungemessen statt automatisch fehlend.
Verwenden Sie ein autorisiertes, verifiziertes Ziel. Tarif und Profil bestimmen Module; zusätzliche Engines müssen separat verfügbar sein. Lesen Sie die Abdeckung vor Vergleichen.
Zertifikatsfehler von Richtlinienbefunden trennen
Ein abgelaufenes Zertifikat kann Kunden sofort aussperren. Eine fehlende Referrer-Richtlinie hat andere Folgen und Dringlichkeit. Beginnen Sie mit Hostname, Weiterleitungsziel, Ablaufdatum und Vertrauensfehler. Betrifft es CDN, Ursprung oder einen einzelnen Namen? Ein gültiges Zertifikat für die Hauptdomain umfasst nicht automatisch alle Subdomains.
Die native Prüfung meldet beobachtete alte Protokollverhandlung und nahenden Ablauf. Eine TLS-1.3-Verbindung beweist nicht, dass ältere Versionen deaktiviert sind. Dafür sind die Terminierungskonfiguration und ein entsprechend abgegrenzter Protokolltest zu prüfen.
Nach Wirkung priorisieren
| Befund | Typische Priorität | Nützlicher Beleg |
|---|---|---|
| Zertifikat abgelaufen oder nicht vertrauenswürdig | Hoch | Hostname, Ablauf, Vertrauensfehler |
| Ablauf nähert sich | Mittel; mit Restzeit dringlicher | Resttage und Erneuerungsstatus |
| HSTS, CSP oder Frame-Schutz fehlt | Oft mittel; kontextabhängig | Antwortheader und Seite |
| nosniff oder Referrer-Richtlinie fehlt | Meist niedrig | Headerwert und Inhaltstyp |
| CORS-Wildcard bei öffentlicher Ressource | Kontext prüfen | Datensensibilität und vorgesehene Nutzer |
Fehlende CSP beweist kein XSS; vorhandene CSP macht XSS nicht unmöglich. CORS-Wildcards können bei öffentlichen Ressourcen beabsichtigt sein. Bei privaten Daten zählen tatsächliche Authentifizierung und Origin-Verhalten. Nicht jede Beobachtung ist ein bestätigtes Datenleck.
CSP anhand von Belegen ausrollen
Erfassen Sie Skripte, Fonts, Bilder, Verbindungen, Frames und Zahlungsanbieter. Testen Sie zuerst mit Content-Security-Policy-Report-Only. Dieser Modus zeigt mögliche Störungen, blockiert aber nicht. Für zentrale Meldungen benötigen Sie ein passendes Berichtsziel.
Content-Security-Policy-Report-Only: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'Das ist ein Beispielstart, keine universelle Produktionsrichtlinie. Externe Dienste benötigen gegebenenfalls ausdrückliche Quellen, Skripte Nonces oder Hashes. Testen Sie Registrierung, OAuth-Fenster, Zahlung, Einwilligung und Fehlerseiten. Beheben Sie legitime Verstöße, bevor Sie die geprüfte Richtlinie erzwingen. Breite Wildcards zum bloßen Verstummen der Meldungen sind keine Lösung.
HSTS als betriebliche Verpflichtung behandeln
HSTS verlangt in unterstützten Browsern HTTPS für eine gespeicherte Dauer. Bestätigen Sie zuverlässiges HTTPS und Zertifikatserneuerung, bevor Sie diese verlängern. Beginnen Sie kontrolliert mit kurzer Dauer und erweitern Sie nach Beobachtung eines stabilen Betriebs.
includeSubDomains umfasst auch Subdomains; prüfen Sie ältere und delegierte Dienste. Preloading hat eigene Browserlisten-Anforderungen und eine möglicherweise langsame Entfernung. Das Wort preload meldet eine Domain nicht automatisch an. Übernehmen Sie keine lange Dauer mit allen Subdomains allein zur Beseitigung einer Scannerwarnung.
Die tatsächlich ausgelieferte Antwort prüfen
Ändern Sie den wirksamen TLS-Terminator und die antwortende Schicht. Eine korrekte Ursprungsdatei kann wirkungslos bleiben, wenn das CDN Header überschreibt. Doppelte Richtlinien mehrerer Schichten können unerwartet zusammenwirken. Vergleichen Sie finale Antworten von Startseite, Anmeldung, Anwendung und Fehlerseiten statt nur Konfigurationsdateien.
Nutzen Sie Secure und HttpOnly passend für Sitzungscookies; wählen Sie SameSite nach dem tatsächlichen seitenübergreifenden Ablauf. Eine JavaScript-lesbare Präferenz ist kein Sitzungstoken. Kombinieren Sie nosniff mit korrekten MIME-Typen. Weniger Versionsoffenlegung ersetzt keine Patches. Die OWASP-Header-Hinweise erklären die Kontrollen einzeln.
Sicherheit und Funktion gemeinsam erneut testen
- Vertrauenswürdiges Zertifikat und erwartete Daten für den richtigen Host bestätigen.
- Tatsächliche Richtlinien nach Weiterleitungen und Cache-Aktualisierung prüfen.
- Registrierung, Anmeldung, Abmeldung, Zahlung und Einbettung in unterstützten Browsern testen.
- Gleiche Module wiederholen und unvollständige Prüfungen mitlesen.
- Erneuerungsüberwachung und erprobte Rücknahme von Richtlinien beibehalten.
Bei sporadischen TLS-Fehlern Belege sichern und aus einer anderen relevanten Netzposition wiederholen, bevor Sie die gesamte Website für ausgefallen erklären. Ein erfolgreicher Test schließt die Beobachtung, nicht jedes Transportrisiko. Ergänzend helfen die OWASP-TLS-Hinweise.
Häufige Fragen
Entfernt Report-Only den Befund fehlender CSP?
Es ist eine Testphase ohne Durchsetzung. Die Warnung kann bleiben, bis ein funktionierender Content-Security-Policy-Header eingesetzt ist.
Sollte ich HSTS-Preload sofort aktivieren?
Erst nach Prüfung der Anforderungen, Subdomains und betrieblichen Folgen. Es ist nicht für jede Domain eine sichere Voreinstellung.
Warum bleiben Header bei Zertifikatsfehlern ungemessen?
Die verifizierte HTTPS-Anfrage lieferte keine nutzbaren Header. Der TLS-Fehler ist belegt; fehlende HTTP-Belege rechtfertigen keine erfundenen Header-Mängel.
Quellen und weiterführende Links
- MDN: CSP-Berichtsmodusdeveloper.mozilla.org
- MDN: HTTP Strict Transport Securitydeveloper.mozilla.org
- OWASP: HTTP-Headercheatsheetseries.owasp.org
- OWASP: Transport Layer Securitycheatsheetseries.owasp.org
Vom Sitelemetry-Team mit dem Prüfumfang des Produkts und verlinkten Primärquellen abgeglichen. Beispiele dienen der Veranschaulichung, sofern kein beobachteter Fall ausdrücklich genannt wird.
