How we protect your account and data
Every guarantee on this page maps to code that ships today — no aspirational claims. EzraLink.org is built for teams that care about what happens after the scan.
Architectural guarantees
Cryptographic signing, database-level isolation, and least-privilege access — the defaults, not the upsells.
Your data isn't our product
We don't sell scan, visit, or account data to third parties, share it with advertisers, or use it to train AI models — ours or anyone else's. The only purpose is powering the analytics in your own dashboard.
HMAC-signed webhooks
Every outbound webhook payload carries an X-EzraLink-Signature (HMAC-SHA256) header plus a timestamp so your endpoint can verify authenticity and reject replayed requests.
Zero card data on our servers
Scan-to-pay hands off directly to Stripe Checkout. Card numbers never touch our infrastructure — we don't see, log, or store them. PCI scope stays minimal.
Row-level data isolation
Postgres row-level security enforces organization boundaries at the database layer. Even if application code had a bug, the database itself refuses cross-org reads.
Role-based team access
Owner, admin, editor, and viewer roles enforced server-side on every mutation. Invite members by email, revoke access instantly. No accidental admin upgrades.
Password-protected QRs
Optionally gate any QR destination with a password. Per-row salt plus HMAC-SHA256 hashing, rate-limited unlock flow, constant-time compare on verify.
Verified custom domains
Bring your own domain for QR URLs. TXT-record ownership verification before certificates provision — no mis-issued SSL for domains you don't actually control.
Account-level safeguards
What's in place on every account, by default.
Two-factor sign-in (optional)
We support authenticator-app (TOTP) two-factor sign-in and one-time backup codes for recovery. It's optional — you can skip setup at signup and turn it on at any time from Settings → Security — but we strongly recommend it for any account that touches billing or holds customer scan data.
Re-prompt before sensitive actions
Even after you're signed in, we ask for your password again before showing Settings or Billing. One confirmation unlocks both for 15 minutes; after that we ask again. Stops a stolen laptop or shared browser from changing your email, your payment method, or deleting the account.
Sessions have a maximum lifetime
Every signed-in session is capped at 30 days regardless of activity. After that you re-enter your password from scratch — a stolen session cookie has a hard expiry it can't escape.
Sign-in throttling
Repeated failed sign-in attempts, MFA challenges, and password-reset attempts are rate-limited per account. Bots can't grind passwords or codes in a loop.
Password strength enforced server-side
Minimum length, character classes, and reuse-check against your recent passwords. Validated on the server so a tampered client can't slip a weak password through.
Sudo-mode webhooks for partners
Outbound webhooks carry an X-EzraLink-Signature (HMAC-SHA256) header plus a timestamp so your endpoint can verify authenticity and reject replays. Keys can be rotated without disrupting deliveries.
Data & infrastructure
- All traffic is served over HTTPS with HSTS — browsers refuse to fall back to plaintext after the first visit.
- Data at rest in our database is encrypted by the provider.
- Row-level security policies are enforced at the database itself, not just in application code. A query run by one organization cannot return another organization's rows.
- Internal RPCs use the principle of least privilege: anonymous and end-user roles are explicitly denied execute on functions that don't belong to them.
- Customer data is processed only by the vendors listed in our Privacy Policy. We do not use it to train AI, sell it to data brokers, or share it with advertisers.
Trust & safety on every scan
Most QR-platform abuse risk is downstream of the redirect. We mitigate it before the scanner ever leaves our domain.
- Every QR destination is checked against Google Safe Browsing before redirecting; confirmed malware or phishing pages are blocked with a notice instead of opening.
- URLs are validated against a strict allow-list (http/https only, no javascript:, data:, file:, or private IPs) at create time and again at redirect time.
- Bot user agents, headless browsers, and suspicious IP clusters are auto-flagged so your analytics stay clean.
- Anyone can report a link they believe is being misused through the public abuse report form; confirmed violations are disabled and repeat offenders are removed.
Reporting a security issue
Found a vulnerability or something that doesn't look right? Please email security@ezralink.org. Include a description, the steps to reproduce, and (if helpful) your contact details for follow-up. We treat reports confidentially and respond as quickly as we can. If you can't send email, click Contact support in the footer.
See also: our Privacy Policy, Terms of Service, and DMCA policy.