GlitchReplay
Browse docs

Security signals

Your error data is full of underused security signal. We surface it instead of throwing it away.

Most error trackers drop CSP violations, 404 scanner probes, and failed-login bursts on the floor — they're "not real errors." GlitchReplay keeps them, classifies them, and shows them on the same dashboard as your application errors. There's no second product to buy and no second SDK to install.

Categories

CategoryWhat triggers it
CSP violationA report-to / report-uri directive fires against your CSP — inline script, blocked origin, frame-ancestors, etc.
Scanner probe404s on common attack paths (/.env, /wp-admin, /.git/config, etc.) clustered by source IP.
Auth spikeA burst of failed-login or 401/403 events on a single account or IP.
Geo anomalyAn authenticated session showing up from a country never seen for that user before.
XSS attemptReflected payloads in error messages — <script>, onerror=, javascript: URIs.

Wiring CSP reports

CSP violation reports go to a project-scoped endpoint (separate from the regular envelope path). Add the URL as a report-uri / report-to directive on your existing CSP header:

Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'nonce-abc123';
  report-uri https://glitchreplay.com/api/<project_id>/csp/?sentry_key=<dsn_public_key>;

For modern browsers using the Reporting API, set up a Reporting-Endpoints header instead:

Reporting-Endpoints: csp-endpoint="https://glitchreplay.com/api/<project_id>/csp/?sentry_key=<dsn_public_key>"
Content-Security-Policy:
  default-src 'self';
  script-src 'self';
  report-to csp-endpoint;

The endpoint accepts both legacy application/csp-report bodies and modern application/reports+json batches. Reports are upserted into the issues table directly — no queue, low volume — and always 204 so browsers don't retry.

Suggested starter CSP

If your site doesn't have a CSP yet, this is a sane Report-Only starter that surfaces violations without breaking the page. Promote to enforcing once the dashboard is quiet:

Content-Security-Policy-Report-Only:
  default-src 'self';
  script-src 'self' 'unsafe-inline';
  style-src 'self' 'unsafe-inline';
  img-src 'self' data: https:;
  connect-src 'self' https://glitchreplay.com;
  report-uri https://glitchreplay.com/api/<project_id>/csp/?sentry_key=<dsn_public_key>;

How classification works

The consumer worker runs a heuristic classifier on every event before it writes to D1. It tags issues with one of the categories above (or none, for ordinary application errors). On Business and above, the classifier also correlates IP-clustered probes against known scanner fingerprints and published CVE feeds.

Filtering and alerts

  • The dashboard's Security tab on each project shows only security-categorized issues.
  • The Issues page has a category filter so you can hide security noise from your normal triage flow if you prefer.
  • You can route security-categorized events to a different alert channel — PagerDuty for auth spikes, a Slack channel for scanner probes, etc. See Alerts.

What this is not

GlitchReplay is not a SIEM. There is no log retention beyond the issue record, no compliance-grade audit trail, and no detection logic for sophisticated attackers. Use it as a low-friction signal layer that catches the obvious stuff your error data already contains.

Next: configure alerts, or pull data into your own systems with the REST API.

← Back to home