Security

1. Hosting and encryption

QR Wait runs on Cloudflare's network (Workers and Durable Objects) and stores its data there. Every connection is encrypted with HTTPS (TLS), and browsers are told to use only HTTPS on qrwait.app and all its subdomains (HSTS, one year).

The pages carry a strict Content Security Policy: scripts load only from QR Wait and Cloudflare, and no other website may show QR Wait inside a frame.

Cloudflare states that it holds ISO/IEC 27001, ISO/IEC 27701 and ISO/IEC 27018 validations (Cloudflare Trust Hub). These are Cloudflare's; QR Wait itself holds no certification.

2. Accounts and sign-in

• Passwords are stored only as a salted PBKDF2-SHA-256 hash. A new password that appears in known data breaches is refused; for that check only the first 5 characters of its SHA-1 hash leave QR Wait (k-anonymity).
• Two-step sign-in with an authenticator app (TOTP), with single-use recovery codes. Owners see which team members have turned it on.
• Team members have a role (owner, manager or attendant) and, if limited, open only the queues they were given.
• After 5 failed sign-ins to an account within 24 hours, signing in also needs a bot check (Cloudflare Turnstile).
• An email goes out when the account is signed in from a new browser.
• A session ends after 14 days without use; changing the password or "sign out other devices" ends all the others.
• Verification, password reset and invitation links are single-use, and only their hashes are stored.

3. Rate limits

Requests are limited per IP address at Cloudflare's edge: signing in, signing up and password resets 10 a minute, joining a queue 60 a minute, the REST API 120 a minute per key and 120 a minute per IP address.

4. Visitors' data

• Visitors are never asked for a phone number or email address. A name is asked only if the business turns it on for the queue.
• A ticket, with the name and join form answers in it, is deleted at the latest 24 hours after joining, whatever the queue's settings.
• No location is stored. When a queue checks location, only the distance to the queue and when it was measured are kept with the ticket.
• A QR code shown on the attendant's screen changes every 15 to 75 seconds and each code works for 1 to 5 minutes, so a photo shared elsewhere gets nobody in.
• What attendants do in the panel is logged for 30 days; attendant links can be withdrawn at any time.

5. Backups

What can't be rebuilt (accounts, queue settings, ticket balances) is exported every day to Cloudflare R2 and encrypted before it is written: each part with its own AES-256-GCM key, which is itself encrypted with a public key (RSA-OAEP). The private key that opens them is kept offline. Exports are kept for 35 days.

Tickets are never in a backup: they hold visitor names and live at most a day.

6. Integrations

• Webhooks are signed (HMAC-SHA256 with a timestamp) with a secret shown once, and go only to public https addresses. They carry numbers and times only, unless the business allows names for an endpoint.
• API keys are shown once and stored only as a SHA-256 hash. A key either only reads or also writes, and can be revoked at any time.
• Details for developers: the API and webhooks reference (in English).

7. Sub-processors

These companies process data on QR Wait's behalf to run the service:

Browser notifications go through the push service of the visitor's own browser. How data leaves Turkey and the EU is explained in the privacy policy.

8. Reporting a vulnerability

Write to hello@qrwait.app with the subject "Security". We confirm within 3 working days and send a first assessment within 10 working days. Please keep the problem to yourself until it is fixed, and test only with your own accounts and queues.

We won't take legal action against research that follows these rules in good faith. There is no paid bug bounty. The same contact, machine-readable: security.txt.