Security

• The application and its PostgreSQL database run on servers operated by Hetzner in Germany.
• Cloudflare sits in front of every AnyReplay hostname, providing TLS, caching and protection against attacks. The servers accept web traffic only from Cloudflare’s network.
• Recordings are being moved to Backblaze B2 object storage, in a private bucket reached with a key scoped to it. Backups use a separate key that cannot touch the recordings.
• Every provider that touches customer data is listed on the sub-processor page.

• In transit: TLS everywhere — from the browser to Cloudflare, and from Cloudflare to our servers using a Cloudflare origin certificate.
• Recordings in object storage are encrypted at rest by the storage provider (SSE-B2).
• Database backups are encrypted with AES-256 on our own server before they leave it, so the storage provider cannot read them.
• The server’s own disks are not encrypted. The database and any recordings still on the server rely on the data centre’s physical security and on access controls.
• Passwords are hashed with Argon2id. Session tokens, verification and reset links, invitations and sign-in codes are stored only as hashes.

• Passwords, payment card fields, one-time codes and any value shaped like a card number are masked on the visitor’s device — in their browser, or in the app on their phone — before anything is sent, in every configuration. No setting records them. Email addresses and telephone numbers are not on that list: they are ordinary contact details, treated like any other form field.
• Every other form value is masked by default too, in every SDK. A customer who wants to see what people type turns that off with maskAllInputs: false; the fields above stay masked even then. Text typed into a rich-text editor is masked with maskAllTyping, and any element with the ar-mask class (a testID containing ar-mask, in a mobile app). Masking always happens on the device, so a masked value never reaches us. Elements marked ar-block are left out of the recording entirely.
• The recorder can wait for consent before recording anything.
• Visitors’ IP addresses are used in memory for rate limiting and are not stored. The recording endpoint keeps no access log; the dashboard and API access logs keep only a truncated address (IPv4 /24, IPv6 /48) and no query strings.
• A session does carry an approximate country and city, with a region and time zone. We do not derive them: our network provider resolves the address as the request passes through it and sends us only the answer, which we record once at the start of the session and never update. The postcode it also offers is not read, and a deployment with no such network in front of it records no location at all.
• Error reports sent to our monitoring provider have request bodies, cookies, IP addresses and user details removed, and query strings redacted.
• Recordings are deleted automatically when they pass the retention period each organisation sets; a sweep runs every few hours. An organisation sets that period between one day and the ceiling its plan allows, and a new one starts at fourteen days.

A recording is a description of a page, not a video, and a page can contain hostile markup. Replays therefore run inside an iframe sandboxed without permission to run scripts, and recorded scripts are rebuilt as inert elements. A recording cannot execute code in the dashboard or reach a reviewer’s session.

Translation sends a recording’s visible text, and Argus a digest of the session, to the AI provider on the sub-processor page, and only when someone in the organisation asks. An owner or admin can turn both off in the organisation settings; from then on nothing from that organisation’s recordings is sent to an AI provider, by anyone, AnyReplay staff included.

• Every organisation’s data is isolated from every other’s; every query is scoped to the organisation it belongs to, and automated tests check that one tenant cannot read another’s data.
• Five roles — owner, admin, moderator, member and viewer — decide who can view, delete, export or erase recordings, invite people or change settings. Nobody can grant a role as high as their own, and ownership moves only by an explicit transfer.
• Two-step verification: a code emailed at every sign-in, which each person can switch on. Google sign-in is also available.
• Failed sign-ins lock an account for a while, and sign-in attempts are rate limited per address.
• An audit log records sign-ins, membership and role changes, deletions and other sensitive actions; owners and admins can read it in the dashboard. Actions taken by AnyReplay staff through internal tools are recorded in a separate audit trail.
• AnyReplay staff access customer data only to operate the service or when a customer asks for help.

• Every change is built, type-checked and run through the automated test suite in CI, and a deployment cannot ship a build that fails.
• The API tests run against a real PostgreSQL engine, not mocks, including tests for permissions and tenant isolation.
• Dependencies are pinned in a lockfile and installed exactly as locked.
• The recorder that runs on customers’ sites has a size budget enforced in CI.

• The database is backed up every night, encrypted with AES-256 on our own server before it leaves, to off-site object storage, and backups are kept for 30 days. While recordings are stored on the server rather than in object storage they are backed up with it, so a deleted recording can survive in an encrypted backup for that long.
• Once a week a backup is automatically restored into a scratch database and checked.
• A recording we delete — retention, a deleted session or project, an erasure request — leaves the service at once. A copy on our own server is deleted with it; a copy in object storage is hidden by the storage provider immediately and its bytes removed 7 days later. So “deleted” means gone within 7 days rather than in the same instant. The window is deliberate: it is what would let a deletion nobody intended, a bug or a stolen key, be undone while it still can be.
• External uptime checks run every ten minutes; host health checks run every fifteen; application errors are reported as they happen.

If a security incident affects customer data, we will tell the owners of affected organisations without undue delay and within 48 hours of becoming aware of it, with what we know and what we are doing, and keep them updated. The commitment is part of our data processing agreement.

• We do not hold SOC 2 or ISO 27001 certification yet, and we will not claim to until an auditor says so.
• A GDPR data processing agreement is available to every customer and can be accepted from the dashboard.
• Our privacy policy describes what we collect and why.
• Answers to security questionnaires are available on request.

If you believe you have found a security problem in AnyReplay, email [email protected] with enough detail for us to reproduce it. English or Turkish is fine. We will acknowledge your report within three business days and keep you told as we fix it.

In scope:

• anyreplay.com, including the dashboard, and api.anyreplay.com, in.anyreplay.com and cdn.anyreplay.com.
• The AnyReplay recorder packages published on npm.

Out of scope: denial-of-service and volumetric testing, social engineering of our staff or customers, physical attacks, and the infrastructure of our providers.

Safe harbour. If you make a good-faith effort to follow this policy — test only against your own account and data, do not access, change or keep other people’s data beyond what is needed to show the problem, do not degrade the service, and give us reasonable time to fix the issue before telling anyone else — we will not take legal action against you or ask anyone else to, and we will treat your research as authorised.

We do not run a paid bug bounty yet. We are glad to credit you publicly once the issue is fixed, if you would like that.