Verstärkte CSP ist vorhanden
Überprüfung der Richtlinien und des realen Ressourcenbedarfs; die Präsenz allein macht die Politik nicht stark.
default-src 'self'; script-src 'self' 'unsafe-inline'; img-src 'self' data:; object-src 'none'Antwort-Header, CSP, Cookies und CORS auditieren und anschließend praxisnahe Deploymentschritte generieren.
Wiederholte Header wie Set-Cookie bleiben erhalten.
Überprüfung der Richtlinien und des realen Ressourcenbedarfs; die Präsenz allein macht die Politik nicht stark.
default-src 'self'; script-src 'self' 'unsafe-inline'; img-src 'self' data:; object-src 'none'Bevorzugen Sie Nonces oder Hashes für Skripte und entfernen Sie inline-style Zugabe, wenn die Anwendung zulässt.
'unsafe-inline'Nach der Validierung der HTTPS-Berichterstattung, erhöhen max-age in Richtung auf eine langlebige Produktionspolitik.
max-age=86400Betrachten Sie includeSubDomains erst nach Überprüfung von HTTPS für den kompletten Namespace.
max-age=86400Der Nosniff-Wert ist konfiguriert.
nosniffÜberprüfen Sie, dass seine ursprungsübergreifende Offenlegung den Datenschutzbedürfnissen der Anwendung entspricht.
strict-origin-when-cross-originDeaktivieren Sie ungenutzte Browser-Funktionen und delegieren Sie erforderliche Funktionen eng.
—Die Antwort begrenzt, welche Seiten diesen Inhalt rahmen können.
SAMEORIGINCross-Origin-Opener-Policy kann Top-Level-Browsing Kontexte isolieren, wenn kompatibel.
—Cross-Origin-Resource-Policy kann einschränken, welche Seiten diese Ressource lesen.
—Dies kann für öffentliche Ressourcen korrekt sein; nicht für private benutzerspezifische Daten verwenden.
*Sitzungs- und sensible Cookies markieren Sichern, damit Browser diese nur über HTTPS senden.
sessionCross-Site-Cookies mit SameSite=Keine müssen auch Secure verwenden.
sessionVerringern Sie unnötige Produkt / Version Details, während die Erinnerung daran, dass sie zu verstecken ist keine Sicherheitskontrolle.
demo/1.0Fügen Sie einen unformatierten Headerblock ein, importieren Sie eine HAR-Antwort oder versuchen Sie explizit eine Browser-URL-Überprüfung mit ihren CORS-Einschränkungen.
Untersuchen Sie gewichtete, evidenzbasierte Ergebnisse für CSP, HSTS, Framing, Referrer, Berechtigungen, ursprungsübergreifende Isolierung, CORS und Cookies.
Erstellen Sie einen geeigneten CSP, überprüfen Sie den generierten Header-Satz und kopieren Sie einen Ausschnitt für Ihre Bereitstellungsplattform.
Nein. Dies ist eine Überprüfung der Antwortkonfiguration, kein Schwachstellenscan, Penetrationstest oder Compliance-Zertifizierung.
CORS kann verhindern, dass eine Webseite eines Drittanbieters die Antwortheader einer anderen Site liest. HAR oder kopierte Header bewahren die Beweise, die Sie lokal überprüfen können.
Ja. Wiederholte Header bleiben erhalten und jedes Cookie wird separat auf sicheres, HttpOnly-, SameSite-, Präfix-, Domänen- und Pfadverhalten überprüft.
Nein. Beginnen Sie, wo praktisch möglich, mit „Nur Berichten“, inventarisieren Sie echte Ressourcenursprünge, testen Sie jeden Benutzerfluss und verschärfen Sie die Richtlinie für Ihre eigene Anwendung.
Arbeiten Sie mit weiteren fokussierten Browser-Hilfsmitteln weiter.