Report a suspected vulnerability
Email [email protected] with the subject Security report. Include the affected domain or feature, the time observed, expected and actual behaviour, and minimal steps to reproduce using your own account. Redact personal information and secrets. Ask for an agreed secure transfer method before sending sensitive supporting material.
Keep testing within your authority
Use only accounts and data you control. Stop as soon as you can demonstrate a concern without accessing another person's data. Do not extract datasets, change payments, deny service, send unsolicited messages, perform social engineering or test third-party providers. Finding a vulnerability does not authorise further exploitation. Request written permission before any active production assessment.
No standing bounty or safe-harbour promise
This page provides a reporting route. It does not announce a paid bug-bounty programme, promise a reward, authorise otherwise unlawful testing or bind a third party to legal safe harbour. Coordinate any planned research scope with us in writing.
Account protection
Use unique credentials, review role and branch assignments, protect the email account used for recovery, and revoke access when employment or provider relationships change. Never send a password or one-time code to someone claiming to be support. Restrict access to downloaded reports and uploaded bank-receipt evidence.
Merchant and provider credentials
A restaurant should use its own approved gateway and messaging accounts. Submit secrets only through the intended authenticated settings workflow. If a key is exposed, rotate or revoke it with the provider and notify the account owner. A saved credential or a successful local test is not evidence of a verified live transaction or message-delivery contract.
Assurance boundaries
Application safeguards and local regression tests provide evidence about specific behaviour. They do not establish a completed independent penetration test, ISO or SOC certification, a guaranteed recovery time or production infrastructure acceptance. Those assurances require separate current evidence. No such certification or uptime commitment is made through this draft.
Incidents and recovery
Suspected incidents should be investigated and contained with appropriate preservation of evidence. Notifications and reporting must follow applicable law and the agreed contract. Backup creation, retention, offsite storage and restore testing depend on the actual deployment; do not assume they have been verified because a backup screen or module exists. Ask for the approved recovery scope when it is a purchasing requirement.
Coordinating disclosure
After a report, agree a safe way to clarify evidence and discuss remediation before publishing details that could expose users. We cannot promise a fixed response or remediation deadline through this draft. This request does not override a legal reporting obligation or restrict lawful contact with a competent authority.