Security Notice

Last Updated: June 13, 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 (June 13, 2026): 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: You can export your per-user key at any time and decrypt your destinations yourself — including directly from the public on-chain record — independently of us.
On-chain payload: When a redirect record is anchored to the public Base L2 blockchain, only the encrypted payload is written on-chain, so public blockchain observers cannot read your destinations.

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

Isolated Storage: Files uploaded via our file-hosting feature are stored in isolated directories (uploads/<file_id>/<filename>) on local server storage.
Access Scoping: File access is restricted by account and workspace scopes to prevent unauthorized file access.

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.