Security and data protection

• Database: Supabase, EU region (Frankfurt).
• Application: Vercel, Frankfurt (fra1).
• Network: Cloudflare in front of the application — DDoS protection, a web application firewall and a front door that refuses traffic which did not come through it.
• Payments: Stripe. Card numbers never touch MySentry.

Connections to MySentry use TLS 1.3. On 22 August 2026 the key exchange negotiated on both hops — visitor to edge and edge to origin — was the hybrid post-quantum group X25519MLKEM768 (classical X25519 combined with ML-KEM-768, FIPS 203), which protects recorded traffic against a future quantum adversary (“harvest now, decrypt later”). Check it yourself with OpenSSL 3.5 or newer:

echo | openssl s_client -connect www.mysentry.co.uk:443 -groups X25519MLKEM768 2>/dev/null | grep Negotiated
# Negotiated TLS1.3 group: X25519MLKEM768

The boundary: the certificate and the signatures that authenticate the connection are classical (ECDSA/RSA), as they are for virtually every website today. That is an authentication concern for a future adversary, not a confidentiality one for traffic recorded now.

• Storage is encrypted by the database provider (AES-256), in the EU.
• Email addresses and phone numbers in error messages, stack traces, URLs and metadata are masked on the server before being written.
• Analytics stores no IP addresses, no cookies and no per-visit records — only daily totals.
• Reporting keys are stored as SHA-256 hashes; the plain key is shown once and cannot be recovered, by you or by us.
• Slack webhook URLs are held in a table that only the server can read; the panel learns whether one is set, never its value.

Access control is enforced in the database with row-level security, not only in the application: every query runs as the signed-in user and the database itself refuses rows that belong to another account. A bug in the application cannot turn into a cross-customer data leak, because the application has no path to that data. All privileged writes go through server-side actions that verify the session, prove access with a scoped read, and record the action in an audit log.

Reporting keys are write-only: a leaked key lets someone submit noise to one website (bounded by rate limits) and nothing else. Browser reports and analytics are additionally restricted to the origins you allow.

• Email and password, with optional time-based one-time codes (TOTP) enforced on every sign-in once enrolled.
• Passkeys (WebAuthn) as a passwordless alternative.
• Sessions are verified server-side on every request to the panel; the panel is never indexed and answers 404, not 403, to anyone who should not see it.

• Every request body is validated against a strict schema and capped at 32 KB.
• Rate limits per key (600/min) and per IP (30/min for browser reports) are enforced in the database, so they hold across every server instance.
• Fingerprints are computed on the server — a reporter cannot choose how its events are grouped or flood the account with unique rows.
• Error responses carry no detail that would help probe the system; a failed CRON secret is logged as a security event.

MySentry’s health endpoint is checked from outside its own infrastructure, its sweep runs every minute, and the sites of the people who built it run on it. The front door is deliberately fail-open: a misconfigured secret degrades to “origin unprotected”, never to “alerts are down”, because a monitoring service that takes itself down over a typo has failed at its one job.

Email [email protected] with the details. We will acknowledge the report, keep you informed, and credit you if you wish. Please do not test against other customers’ data.

Processors and retention are listed in the privacy policy.