Trust
How QRDinesOS keeps your data safe
What we do at the database, the app, and the browser. Written for the person asking the Enterprise-sales security question — no jargon padding.
At the database
Every table that carries tenant data has PostgreSQL row-level security enabled. The application connects as a role with NOBYPASSRLS, and every request sets a SET LOCAL app.restaurant_id for the duration of the query. A route that forgets a WHERE clause reads zero rows from another tenant — Postgres itself refuses.
Database protection and recovery use the configured Neon project's encrypted storage, history, and restore controls. Exact backup and point-in-time recovery windows follow the contracted database plan; QRDinesOS does not publish a longer retention promise than the active provider configuration supports.
At the app
- Owner sessions and staff sessions are HMAC-signed cookies with a versioned epoch. Resetting a password or suspending an account bumps the epoch and signs every existing device out.
- Owner passwords and staff PINs are stored as bcrypt hashes. We cannot recover them — a lost password is reset, not retrieved.
- Staff PIN sign-in is rate-limited per IP and per restaurant, so a stolen tablet cannot be walked through the 10,000 possible PINs.
- Every write to a tenant's configuration is written to an audit log with the actor, timestamp, and the specific fields that changed.
- Roles are enforced at the request boundary through a single capability model. A waiter physically cannot open the settings screen because the API refuses; the button not being there is a UI courtesy, not the security.
Payments
We never see card numbers, CVVs, UPI PINs, or bank credentials. All configured gateway collection is handled by Razorpay. When a gateway payment succeeds, Razorpay signals QRDinesOS through a signature-verified, replay-safe webhook. Direct UPI intents are not treated as proof of payment; staff must verify receipt.
In the browser
- Session cookies are
HttpOnly,Secure,SameSite=Lax. No JavaScript on the page can read them. - No third-party analytics, no ad networks, no session-replay tools. We know nothing about a diner beyond what they type at a table.
- The guest ordering page ships as static HTML wherever possible, so a slow phone at a real restaurant still gets a menu.
Isolation
Tenant-owned records are scoped by restaurant in application queries and protected by PostgreSQL row-level security where the data model is tenant owned. Deliberate platform support and impersonation paths are separately authorized and audited with the operator and affected restaurant.
Where it lives
The application runs on Cloudflare Workers with Neon Postgres and Cloudflare storage bindings configured per environment. Browser traffic is encrypted in transit, while secrets and production bindings are kept outside the source tree and supplied through the deployment environment.
Reporting a vulnerability
Please email contact@cognorotechnologies.com with the details. We reply within 3 working days, and we don't threaten researchers who act in good faith.
What we do not have (yet)
Honesty matters more here than a certificate we haven't earned:
- We do not currently hold a SOC 2 or ISO 27001 report. Enterprise procurement should evaluate the controls and evidence available today rather than assume certification.
- External AI, automated WhatsApp, Razorpay, printer, and delivery-platform workflows require the relevant production credentials, provider approval, or hardware validation.
- PF, ESIC, professional-tax filing, and a complete central-kitchen transfer module are outside the current product scope.
Contact
Cognoro Technologies, Chandigarh, India · Phone/WhatsApp: +91 91151 13222 · Email: contact@cognorotechnologies.com