Security Notice

Last Updated: August 17, 2026

At eqr.link, security is built into the core architecture of our platform. We implement modern cryptographic standards, secure coding practices, and network-level protections to protect your data, the permanence of your QR redirects, and the safety of scanners.

What changed in this revision (August 13, 2026): Section 1.5 now says exactly what goes on the blockchain, and says plainly that encryption is not anonymisation. Section 4 was rewritten because it described a system we no longer run: hosted files are not on local disk and are not access-scoped by account. They live in a private object-storage bucket, they are served from an isolated domain as non-executable downloads, and their address is a barrier to discovery rather than an authorisation check.

What changed in the June 13, 2026 revision: Section 1 was corrected to describe our encryption accurately. Earlier wording described a "zero-knowledge" / "client-side" approach and stated that we could not view destination URLs. That was inaccurate: encryption is performed on our servers, and our redirect service decrypts destinations at request time to route scans. The inaccurate statements have been removed.

1. Cryptography and Data Encryption

1.1. Per-User Encryption at Rest

Your destination URLs are encrypted at rest. This is server-side encryption — not end-to-end or "zero-knowledge" encryption.

• HKDF Key Derivation: We derive a unique per-user encryption key from a master secret using HKDF-SHA256 (with your user ID as salt).
• AES-256-GCM Encryption: Destination URLs are encrypted on our servers with the per-user key before they are written to the database. The master secret is held in our application environment, not in the database — so a database leak alone does not expose your destinations.
• Operational access: To route a scan to its destination within milliseconds, our redirect service decrypts the destination at request time. Eternal QR systems can therefore access destination URLs in the course of operating the Service. We do not sell them, and we use them only to operate and secure the Service (see our Privacy Policy).
• Recovery key: Owners of paid Eternal codes can export the recovery key for their Eternal records at any time and decrypt those destinations themselves — including directly from the public on-chain record — independently of us. Basic and Dynamic-only codes are hosted rather than anchored, so there is no on-chain record to recover them from.
• On-chain payload: When an Eternal record is anchored to the public Base L2 blockchain, exactly two values are written: the random identifier of the code and the AES-256-GCM ciphertext of its destination. The transaction is signed by our own relayer wallet, so that address is public too. No email address, account identifier, IP address, scan data or plaintext destination is written on-chain. An observer without the key cannot read the ciphertext — but the identifier is the same one that appears in your public link, so while the Service is running that link can simply be followed. Encryption is not anonymisation: we hold the key, and the on-chain ciphertext remains personal data under data protection law.

2. Authentication and Session Management

2.1. PASETO Session Tokens

Instead of standard JSON Web Tokens (JWTs), which are vulnerable to header-manipulation attacks, we use PASETO v4 (Platform-Agnostic Security Tokens) local tokens.

• Expiry: Session tokens have a strict 24-hour expiration lifetime.
• Revocation: When you log out, the token's unique ID (JTI) is inserted into a revoked tokens database. Revoked tokens are immediately rejected.
• Magic Links: Email magic link tokens are strictly single-use and invalidated immediately upon authentication.

2.2. API Key Security

• Format: API keys use the prefix eqr_live_ followed by a workspace prefix and a cryptographically secure random secret.
• Scoping: Keys are workspace-scoped and restrict actions based on granular permission scopes.
• Rate Limiting: API requests are rate-limited at 60 requests per minute (RPM) with a burst allowance of 10 to prevent brute-force attacks and abuse.

3. Server and Network Protections

3.1. Server-Side Request Forgery (SSRF) Guard

To prevent malicious actors from using our redirect engine to scan internal networks or access sensitive metadata, our backend validates all destination URLs:

• Private IP Blocking: We automatically block destination hosts that resolve to loopback addresses (127.0.0.1, ::1), private IP ranges (RFC 1918), and link-local addresses.
• Metadata Protection: Requests to cloud provider metadata endpoints (e.g., AWS/GCP metadata server 169.254.169.254) are strictly denied.
• Scheme Restriction: Only http and https protocols are allowed.

3.2. Edge Redirections

• Stateless Workers: Public scans are routed through Cloudflare Workers. The edge router does not cache personal data or store logs containing raw scanner IP addresses.
• DDoS Mitigation: Cloudflare provides network-layer security and DDoS protection at the edge.

3.3. Database Security

• Query Parameterization: We use the SQLC compiler to generate database queries, ensuring all queries are parameterized to eliminate SQL injection vectors.
• Row-Level Security (RLS): Database operations validate user ownership at the database layer before retrieving or editing data.

4. File Upload and Hosted Content Security

• Validation before storage: We take the expected type of an upload from its file extension, then verify it against the file's own bytes and decode the file in full before storing it. We accept only PDF, PNG, JPEG, GIF, WebP, and SVG, which we sanitise; images are re-encoded, which removes their embedded metadata. The type your browser declares is ignored. Anything we cannot validate is rejected.
• Private storage: Files are held in a private object-storage bucket reached with bucket-scoped credentials. Nothing is publicly listable and there is no directory or index.
• Isolated delivery: Hosted files are served from content.eqr.link, a separate cookieless domain that cannot serve the application, authentication routes, or QR redirects. They are delivered as downloads under a content security policy that denies script execution, framing, and network access, and are marked for exclusion from search engines.
• Link-based access: Each file has an unguessable 128-bit address. That address controls discovery, not authorisation — anyone holding the link can retrieve the file without signing in. Deleting a file removes the stored object and every version of it.
• Rate limiting: Uploads are capped per account per hour and per file, and against the account's storage quota. Retrieval of a hosted file is rate-limited per file and per client.

5. Vulnerability Disclosure Policy

If you believe you have found a security vulnerability in the Service, please report it to us immediately.

• Contact: security@eqr.link
• Please include a detailed description of the vulnerability and steps to reproduce it.
• We request that you disclose vulnerabilities responsibly, allowing us time to remediate the issue before public disclosure.