Security

Last updated 2026-08-27

Architecture

The whole product runs on Cloudflare. The recorder posts to an edge worker that validates and stores; a second worker serves this site and the dashboard. Recording data lives in object storage, compressed, with metadata in a serverless SQL database. There are no long-running servers to patch and no separate analytics pipeline holding a second copy of anything.

Data minimisation, enforced in the browser

The most important protections happen before anything is transmitted, which means they cannot be undone by a mistake on our side:

Input values, including hidden inputs, are replaced as the page is serialized. There is no unmask feature because there is nothing to unmask.
Checkout URLs abort recording entirely.
Sensitive URL parameters are redacted in the address, and also inside every attribute of the page that carries a URL — links, images, stylesheets, form actions.
The redaction runs again server-side on arrival, because the ingest endpoint is public by design and client-side sanitisation alone can be bypassed.

Access control

Passwords hashed with PBKDF2-SHA256 at the platform's maximum iteration count. Session tokens are stored only as SHA-256 hashes, so a database copy cannot be replayed as a login.
TOTP two-factor authentication on any account, free, with single-use recovery codes stored hashed. The second factor applies to social sign-in too.
Four roles, and per-site grants: a member or viewer sees only the sites they are assigned. That is enforced in the database query, not in the interface.
Every replay view, share, deletion and role change is written to an append-only audit log kept for two years — longer than any recording it describes.
Share links carry a hashed 160-bit token, are scoped to one recording, expire, and are revocable.

Handling hostile input

The recording endpoint is public by design — the site key ships in your page source — so everything it stores is treated as attacker-controlled in every place it is later displayed. Compressed uploads are bounded on their decompressed size, not just their transfer size, because a compressed-size cap is not a size cap. Site and session identifiers are pattern-validated before they are ever used to build a storage path.

For your PCI assessor

If you are assessed under PCI DSS 4.0.1, requirements 6.4.3 and 11.6.1 ask you to inventory and justify every script on a payment page. Ours makes that straightforward:

Script URL: https://cdn.replayfy.com/t.js
Purpose: user-experience session replay for the merchant's own analysis.
Payment pages: the recorder detects checkout URLs and stops. It should not be present in your payment-page inventory at all; if it is, tell us and we will help you work out why.
Integrity: the script is versioned and served from a single origin under our control, so you can pin it in your CSP and monitor it for change.

Reporting a vulnerability

Email security@appifycommerce.com. We will acknowledge within two working days. Please give us a reasonable window before disclosing publicly; we will not take legal action against good-faith research that stays within your own account.

What we do not claim

We are a small team and we would rather be exact than impressive. We do not hold SOC 2 or ISO 27001 today, and we will not imply otherwise on a sales call. What we do have is a small attack surface, a short sub-processor list, a product that structurally cannot capture what people type, and the ability to delete one person's data without destroying anyone else's.