Security
Last updated: April 22, 2026
Security isn’t a contract clause — it’s the minimum requirement to run a restaurant on our platform. Here’s how we approach it.
Per-tenant isolation
Each restaurant lives in a fully isolated tenant. Firestore rules (firestore.rules) verify on every read and write that the user belongs to the correct tenant. No query crosses tenants without going through the Admin SDK under super-admin authentication.
Encryption
- In transit: TLS 1.3 enforced across the entire app, API and web.
- At rest: AES-256 (provided by Google Cloud / Firebase).
- Secrets: stored in Google Secret Manager, never in the repository.
Authentication
- Sessions use HttpOnly, Secure and SameSite cookies.
- Firebase custom claims for role, tenant and impersonation.
- MFA required for super-admin roles.
- Cloudflare Turnstile + Firebase App Check on lead-capture endpoints.
Audit logging
Every sensitive action is recorded in an immutable log (auditLog per tenant, platformAuditLog for global actions). Super admins cannot operate as if they were the restaurant without leaving a trace — every impersonation logs who, when and why.
Backups
Automatic daily backups, 30-day retention, encrypted with a key distinct from production. Quarterly restore drills.
Responsible disclosure
If you find a vulnerability, email [email protected] before disclosing it publicly. We respond within 72 hours and publicly credit researchers who follow our process.
What we don’t do
- We don’t use your tenant’s data to train global AI.
- We don’t share your information with ad networks.
- We don’t have a shared “root password” — every admin action is traceable to a person.
Certifications
We’ll publish a security and compliance roadmap as we grow. For now, our practices live in this document and our team is happy to walk through specifics in your demo.
