Security

Every table carries the store it belongs to, and PostgreSQL row-level security decides what a signed-in staff member can read or write. Authorization is not a check in the interface that a crafted request could skip — it is enforced underneath the application.

Owner, manager, order desk, picker, billing and delivery each get what they need and no more. A delivery-only account can read the orders assigned to it and nothing else — not the customer list, not other deliveries, not analytics.

Tracking tokens carry 192 bits of randomness and are stored as SHA-256 hashes. A guessed order number gets nowhere. Public endpoints are rate limited, and the customer page exposes only what a customer needs — never internal notes, staff details or other orders.

Invoices live in a private bucket, never a public one. Staff reach them through their own session; a customer reaches only their own invoice, through a short-lived signed link issued after their tracking token is verified. Uploads are limited by type and size, and the stored filename is generated by the server rather than taken from the upload.

Creating staff accounts and resetting passwords need administrative rights over the authentication system. Those run inside a Supabase Edge Function that re-checks the caller is an active owner of that store. The service-role key stays inside Supabase and is never deployed with the web application.

Several people touch the same order, so OrderDesk keeps a status history and an audit log: who changed the status, who resolved an item, who attached or replaced an invoice, who assigned the delivery and who marked it paid. Replacing an invoice removes the old file and records the replacement.

If you find a security issue, please report it to the store owner or to Techvora before disclosing it anywhere else.