Wer in Produktion eine Content-Security-Policy fährt, hat ein Telemetrieproblem. Browser blockieren still und leise Skripte, Bilder und Stylesheets, die gegen eure Policy verstoßen — ohne report-uri oder Reporting-Endpoints erfahrt ihr davon nichts. Und selbst wenn: Ihr braucht einen Endpoint, der die Reports annimmt, Dubletten zusammenfasst und euch das Signal liefert.
Einen eigenen Endpoint zu betreiben ist machbar, aber nicht trivial — Request-Parsing, Dedup, Retention, Missbrauchsschutz, UI. Die meisten Teams lagern das an einen Spezialanbieter aus.
Ab v1.12 kann jeder SiteGuardian-Monitor sein eigener CSP-Report-Endpoint sein — im bestehenden Plan enthalten, vollständig EU-gehostet und an dieselben Alarmregeln angebunden, die ihr ohnehin schon nutzt.
Was ihr bekommt
- HMAC-signierte URL pro Monitor —
https://reports.siteguardian.io/r/{monitor_id}/{token}. Einfach in denContent-Security-Policy: report-uri …-Header einsetzen (oder das moderneReporting-Endpoints/Report-To-Paar). Beide Formate werden unterstützt. - Aggregation statt Feuerwerk. Eine falsch konfigurierte CSP kann uns aus einem einzigen Browser-Tab mit Millionen Reports fluten. Wir gruppieren nach
(directive, blocked_uri, source_file)und speichern Buckets — aus 1 Mio. Rohreports wird eine Zeile mit Count, drei Samples und Browser-Breakdown. - DSGVO by design. Client-IPs werden mit täglich rotierendem Salt gehasht (nie als Klartext gespeichert). Query-Strings und Fragmente werden aus
document_uri/source_filevor der Speicherung entfernt. Wir behalten die UA-Familie (chrome/firefox/safari), nie den kompletten UA-String. - Rauschfilter. Browser-Extension-Verstöße (
chrome-extension://,moz-extension://), AV-Injektionen unddata:/blob:-URIs werden gezählt und verworfen. Ihr seht, was zählt — nicht, was jemand auf seiner Maschine installiert hat. - Alert-Regeln, die ihr schon kennt.
csp_new_violation_type_countodercsp_report_volumein eine Alarmregel einsetzen — und ihr bekommt einen Alarm, wenn ein neuer Verstoßtyp auftaucht (klassische CSP-Drift-Erkennung) oder das Volumen explodiert (neues Deploy schiefgegangen). - Policy-Empfehlungen. Nach einer Woche Reports schlagen wir Allowlist-Ergänzungen vor — sortiert danach, wie vielen Nutzern die Änderung etwas kaputt-geflicktes repariert.
Aktivieren
Auf jeder Monitor-Detailseite gibt es jetzt einen Tab CSP Reports. Ein Klick legt den Endpoint an; wir erzeugen ein Salt, signieren die URL und geben euch ein Copy-Paste-Snippet:
Content-Security-Policy: default-src 'self';
report-uri https://reports.siteguardian.io/r/69a8b2f…/4e8f1c7d;
report-to sg-csp
Reporting-Endpoints: sg-csp="https://reports.siteguardian.io/r/69a8b2f…/4e8f1c7d"
Report-To: {"group":"sg-csp","max_age":10886400,"endpoints":[{"url":"https://reports.siteguardian.io/r/69a8b2f…/4e8f1c7d"}]}
Header deployen. Sekunden nach dem ersten echten Browser-Traffic erscheint der erste Bucket im Tab. Nach Count sortieren, reindrillen, Samples ansehen — und Policy iterativ enger ziehen.
Rate-Limits und Schutz
Eine einzige misskonfigurierte CSP auf einer viel besuchten Seite kann uns aus einem Browser mit 10 k Reports/s füttern. nginx limitiert am Rand (200 r/s pro Quell-IP, Burst 400), und ein Per-Monitor-Quota pausiert den Endpoint automatisch für eine Stunde, wenn drei Minuten hintereinander über dem Limit liegen. Ihr werdet nie für einen Crawl-Loop auf eurer eigenen Seite belastet.
Enterprise?
Dieselbe Pipeline skaliert. Der Business-Plan enthält 1 Mio. Reports/Monat; darüber hinaus kosten Überschreitungen 0,00005 €/Report. White-Label-Subdomains (reports.eure-domain.de) sind auf der Roadmap.
Warum der Aufwand?
Weil CSP ohne Reporting CSP auf gut Glück ist. Ihr wisst nicht, bei wie vielen Kundensessions jedes Marketing-Tagmanager-Rollout etwas zerschießt. Ihr wisst nicht, wenn ein Vendor-CDN einen neuen Tracker deployt, den eure Policy nicht erlaubt. Und ihr merkt definitiv nicht, wenn jemand versucht, Angreifer-Skripte nachzuladen.
Jetzt wisst ihr es. Und zwar im Plan, den ihr ohnehin schon habt.
— Günter Weber, SiteGuardian