The controls behind the menu.
A transparent snapshot of the security boundaries currently present in the dishreveal MVP and the work still required before production launch.
Current controls
- Restaurant dashboard and model-management routes require an authenticated session and either restaurant membership or a platform owner grant.
- Model callbacks require an HMAC signature before job data is updated.
- Provider API keys, database credentials, storage service credentials, and callback secrets are server-side configuration.
- Public menu reads are limited to published menus and visible categories/dishes in the current data-access path.
Known launch work
- Production configuration must reject development auth bypasses and fallback secrets.
- Rate limits, upload validation, abuse controls, security headers, dependency scanning, secret rotation, and tenant-isolation tests must be evidenced.
- GCS permissions, public/private asset boundaries, provider retention, backups, logs, and incident recovery need review.
- A monitored security-report address and responsible-disclosure process must be published.
Responsible reporting
A dedicated monitored security contact has not yet been configured, so this draft must not claim a complete vulnerability-disclosure program. Once configured, the final page will explain what to report, what information to include, safe testing boundaries, and expected acknowledgement.
Do not include passwords, API keys, session tokens, private restaurant data, or exploit code in the demo contact form. Use Contact only for product-review questions until the monitored route is published.
Availability and disclosure
No online service can promise uninterrupted availability or zero risk. Security notices, material changes, and incident communications will follow the final legal and operational process approved for the launch markets.