Security whitepaper

Controls, data handling, and tenant isolation for security reviewers

ShieldReplay security overview

Security architecture overview · Not a certification

This 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)

Important: The site token in your recording snippet is visible in the browser. Anyone can copy it. Protection comes from your allowed domains list, not token secrecy.

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.

CriteriaShieldReplay control
CC6.1 Logical accessSigned-in user authentication, website membership and role checks
CC6.6 EncryptionHTTPS, AES-256-GCM for automation secrets
CC7.2 MonitoringSecurity incidents, browser probes, automation run history
CC8.1 Change managementAutomation version history and restore
CC9.2 PrivacyIP 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).