Security

• Passwords are hashed with bcrypt — they are never stored or logged in plain text and cannot be read by us.
• Email ownership is verified with 6-digit one-time codes that are stored hashed, expire after 10 minutes, are single-use and are voided after 5 wrong attempts. Resending is rate-limited.
• Password resets use the same hardened code flow and exchange the code for a short-lived, purpose-scoped token that cannot be used as a login session.
• Dashboard sessions use signed JWTs; every request re-checks that the account still exists and is active.

• Role-based access control: owner, branch manager and staff roles see only what their role allows; staff can additionally be scoped to a single dining area.
• Every operational query is scoped to the caller's own restaurant and organization — one restaurant can never read another's data.
• Platform administration is a separate authentication system with its own accounts.

• Table QR codes use opaque, non-guessable tokens — table URLs cannot be enumerated.
• Starting a session requires the physical table PIN, with rate-limited attempts to stop guessing.
• Order submission is idempotent (a double-tap cannot create a duplicate order) and one table can never have two competing primary sessions.
• Every order lands as "pending" for staff approval before the kitchen starts.

• All card/UPI processing is done by Razorpay, a PCI-DSS compliant payment processor. Card details never touch Dinor's servers.
• Every payment confirmation is verified server-side with an HMAC signature before anything activates and the plan purchased is bound to the order created by our server — it cannot be swapped client-side.
• Payment IDs are unique in our database, so a replayed confirmation can never double-charge or double-credit.

• All traffic is encrypted in transit with HTTPS/TLS across every domain (site, app, admin, API), including live WebSocket updates.
• The API accepts browser requests only from the official Dinor domains (a strict CORS allowlist — no wildcards), for both HTTP and WebSocket connections.
• All input is validated server-side; unknown fields are rejected outright.
• Data lives in Supabase (PostgreSQL on AWS) with encryption at rest and managed backups; the API runs on Render and the frontend on Vercel — providers with mature physical and network security programmes.

Dinor is an independent product early in its life: we do not yet hold formal certifications such as SOC 2 or ISO 27001 and there is no public bug-bounty programme. What we commit to is a small, careful codebase, the concrete controls above and fixing reported issues fast.

Found something? Email hqdinor@gmail.com with the subject "Security" and enough detail to reproduce it. Please don't access other people's data or disrupt the service while testing (see the Acceptable Use Policy) — report and we'll take it from there. We acknowledge reports quickly, prioritise fixes and will credit you if you'd like.