01
A practical approach
We design the application around narrow access, verified actions, and recoverable operations. This page describes the safeguards present in the product today, rather than promises about controls we have not implemented.
02
Account access
Passwords are hashed with Argon2id. Sessions use opaque, randomly generated tokens; only token hashes are stored. Sessions can be ended from account settings, and password changes end other active sessions.
03
Verified identity
Email-and-password accounts must verify their address before they can sign in. Optional Google, Microsoft and X sign-in uses the providers’ identity flows, with checks before an existing account can be linked.
04
Protected changes
Important server-side changes are checked again when submitted, not only when a page loads. Administrative actions are recorded, and account, booking, and membership changes use database transactions where consistency matters.
05
Payments and delivery
Subscription state is sourced from Stripe. Webhook signatures are verified before a subscription can grant access, duplicate deliveries are handled safely, and failed processing is returned for Stripe to retry.
06
Service protection
Connections to the public service use HTTPS. Application data is kept separate from deployed source code, and operational safeguards are reviewed as the service grows. We avoid publishing infrastructure details that would make the service easier to target.
07
Report a concern
If you think you have found a security issue, please send a concise report to [email protected]. Do not include passwords, access tokens, or other sensitive secrets in the first message.