Security

Accounts and sessions

• Passwords are stored as a one-way hash (bcrypt); not even we can see your password.
• Sessions live in cookies that page scripts cannot read (httpOnly) and that are only sent to our own site.
• Changing a password, logging out or closing an account ends its open sessions.
• Sign-in attempts are limited per IP address and per account. Accounts are never fully locked, so someone who knows your email cannot lock you out.

Every restaurant in its own space

• Every staff action can only reach that person’s own restaurant.
• Waiters work with orders and tables; managers with the whole restaurant.
• Actions system administrators take inside a restaurant are written to an audit log.

Table QR codes and orders

• Each table’s QR code contains a secret that cannot be guessed. Renewing it makes every printed copy of the old code stop working.
• Every order goes through waiter approval before it reaches the kitchen.
• Order totals are always calculated on the server from your menu prices; a price sent from a phone is never trusted.
• A guest’s table session ends once the order is paid and served, and lasts at most 2 hours.

Storing and moving data

• The application and database run in Germany (Frankfurt). Your connection to the site is encrypted with HTTPS.
• Keys for third-party services are stored encrypted with AES-256-GCM.
• Menu photos are uploaded straight to storage through short-lived signed links that fix the file type and size.
• Input on every request that writes data is validated, and database queries are parameterised.

Reporting a vulnerability

If you think you have found a security vulnerability, please email {{PLACEHOLDER: contact_email}} without sharing the details anywhere public. We aim to confirm we received your report within 3 business days.

Please do not test against real restaurants’ live systems, and do not access data that is not yours.