ShieldReplay security overview
Security architecture overview · Not a certificationThis document describes how ShieldReplay protects customer data and supports security evaluations. It is intended for security reviewers and procurement teams.
Trust principles
- Tenant isolation — Users access only sites they belong to; ingest tokens are registered per site.
- Least privilege — Website roles are Owner, Admin, Member, and Viewer. Access is limited to websites a person belongs to.
- Encryption — TLS protects traffic in transit. Connected automation credentials are encrypted at rest when the deployment's encryption key is configured.
- Auditability — Automation and administrative actions have dedicated audit records.
Allowed origins (ingest security)
ShieldReplay validates the browser Origin (or Referer when Origin is absent) on ingest requests. The ShieldReplay server's own origin is permitted; other website origins must be saved for that site. With an empty list, customer websites on other origins cannot record. Requests from unlisted origins receive 403 Origin not allowed. This browser-origin check complements authentication and tenant checks; it is not a defense against a non-browser client forging HTTP headers.
- Configure domains in Setup wizard step 2 or the admin allowed-origins panel.
- Add every URL scheme + host where the snippet runs (e.g.
https://app.example.com). - Include staging and preview environments separately if they use different origins.
- Rotate the site token if you suspect it was exposed publicly.
SOC 2 readiness mapping (self-assessed)
This mapping describes engineering controls that can support a future audit. ShieldReplay does not claim SOC 2 certification until an independent auditor has issued a report.
| Criteria | ShieldReplay control |
|---|---|
| CC6.1 Logical access | Signed-in user authentication, website membership and role checks |
| CC6.6 Encryption | HTTPS, AES-256-GCM for automation secrets |
| CC7.2 Monitoring | Security incidents, browser probes, automation run history |
| CC8.1 Change management | Automation version history and restore |
| CC9.2 Privacy | IP hashing, configurable retention with automatic purge, session-scoped data |
Data collected
Session replay frames, cursor events, DOM mutations, JavaScript errors, security probe signals, and optional custom events. New sites mask form inputs, textareas, selects, editable content, passwords, and explicit data-shield-mask regions by default. Administrators remain responsible for reviewing selectors before production rollout.
Privacy operations and access accountability
- Replay views are written to a site-scoped access audit containing user, session, action, and timestamp.
- Owners and administrators can export or delete sessions belonging to an identified email or user ID through the privacy API.
- Retention cleanup removes expired sessions and their cascade-linked replay data.
- Network request bodies and console capture are disabled by default; request headers and traits apply sensitive-key redaction.
Incident response
Security incidents are stored with risk scores and replay deep links. Automations can notify Slack, PagerDuty, Jira, or webhooks with investigator context.
Contact
For security questionnaires, contact your ShieldReplay account team or open a ticket with your deployment environment (cloud/self-hosted).