Security
How this is protected.
Version 1.0 · 30 August 2026
For a service whose whole promise is discretion, security is not a back-office concern. This page says what we do, at a level that is useful without handing anyone a map.
Data minimisation
The strongest protection is not holding something in the first place. The application form collects six fields and has nowhere to put a passport number, an itinerary or a payment method. We store a one-way keyed hash of your network address rather than the address itself. We keep no advertising or analytics trackers and set no cookies.
Access
- Applications sit in a database with row-level security enabled and no public policy, so no public or anonymous key can read a single row. Only our server-side code reaches the data.
- The membership desk is password-gated. The password is exchanged once for a short-lived signed session token, so the secret is not re-sent on every request.
- Repeated failed sign-in attempts are rate-limited and locked out, and the lockout is recorded durably rather than held only in memory.
- Operationally, access to a journey is need-to-know: an airport partner, agent or driver receives what their part requires and nothing else.
The application endpoint
The invitation form is the only unauthenticated endpoint that can cause an effect, so it is the most defended. It enforces request-origin checks, a body size ceiling, per-connection burst and hourly rate limits, silent bot traps, and strict validation of every field before anything is stored or sent.
In transit and in the browser
- Served over HTTPS only, with HSTS.
- A Content Security Policy that permits no third-party script, no framing of the site, and no inline script at all.
- Standard hardening headers, and no-store caching on every private and API route.
- The site loads no third-party fonts, scripts, tags or beacons. There is nothing on the page that reports to anyone but us.
Secrets
Credentials live in the hosting platform's encrypted environment configuration, never in the codebase and never in anything the browser downloads. Server error messages are deliberately generic so that a failure cannot be read for information.
What is still being built
Reporting a vulnerability
If you believe you have found a security problem, tell us at concierge@celebassistance.com before telling anyone else. Please give us enough to reproduce it, and please do not access, alter or retain anyone else's data while demonstrating it.
We will acknowledge a credible report, keep you informed while we fix it, and we will not pursue anyone who reports in good faith and acts within these bounds.