Security · Built for the trust restaurants depend on
Multi-tenant isolation, by construction.
Every venue is sealed at the database layer with row-level security. Audit, encryption, rate-limiting, and a strict Content Security Policy are the floor, not a paid add-on.
Posture shipped today
Live6controls shipped · 1 audit ledger
What's actually enforced on every request.
Each control below is in the code that ships today.
Isolation
Row-Level Security on every table
Postgres RLS policies enforce tenant_id on every tenant-bound table. The app's main database connection runs as a role that cannot bypass them, and the database does the check on every row it reads or writes. A limited set of server-only paths, such as webhooks, scheduled jobs, sign-in, file storage and public guest flows like ordering, bookings and QR codes, use a service role that never reaches the browser.
- Postgres RLS
- Per-tenant policies
- Service role server-only
Audit
Immutable audit log
All sensitive writes are recorded with actor, tenant, action, payload, and timestamp. Append-only, exportable, and visible inside the admin surface for the tenant owner.
- Append-only ledger
- Actor + tenant + payload
- Admin UI
- Export
Rate limits
OWASP-aligned rate limiting
Upstash Redis rate limits address OWASP API4:2023, Unrestricted Resource Consumption. Per-route, per-tenant, per-actor: graceful 429s with retry headers, not silent drops.
- Upstash Redis
- Per-route
- Per-tenant
- OWASP API4:2023
CSP
Strict Content Security Policy
A strict CSP, frame-ancestors, HSTS, and Permissions-Policy ship by default on every response. Scripts run only with a per-request nonce, and eval is blocked in production. Inline styles are still allowed.
- Strict CSP
- HSTS
- No eval
- Nonce-only scripts
- Frame-ancestors
Encryption
Encrypted at rest and in transit
TLS 1.3 on the edge, with TLS 1.2 for older clients. Database encryption at rest (AES-256) via Supabase-managed keys. Per-tenant integration secrets saved in the app are encrypted with AES-256-GCM, not kept in plain config.
- TLS 1.2 and 1.3
- AES-256 at rest
- AES-256-GCM secrets
Identity
Supabase Auth with server sessions
JWT issued by Supabase Auth, session enforced via HTTP-only server cookies. MFA enforced on platform-admin accounts. A venue can require MFA for admins and managers, or for everyone. Staff PIN for floor terminals separate from owner credentials.
- Supabase Auth
- HTTP-only cookies
- MFA
- Staff PIN
- RBAC roles
The jurisdictions and frameworks we're built around.
NexDine is built for Australian hospitality first. The food-safety standard we build to is national. Where an obligation is set by a state or territory, we add it when a venue needs it.
Australian-first compliance posture
Australian Privacy Act 1988 (Cth) and the 13 Australian Privacy Principles guide our data handling.
Payroll is calculated to the award. STP lodgement is on the roadmap.
Temperature and cleaning records follow Standard 3.2.2A of the Food Standards Code, which is national.
Found a vulnerability?
We treat security reports as a priority. Email us with the issue and reproduction steps. We aim to acknowledge inside one business day and to patch critical issues in days, not weeks.
Responsible disclosure
hi@thedds.com.au
Please do not test against pilot tenants. Use the staging environment we'll provide on request.
Security · the floor, not the ceiling
Run service on a platform that takes isolation seriously.
We'd rather build trust through the architecture than the marketing. Ask us anything. The answer is usually in code.
Row-level security, audit ledger, strict CSP