Security

How your salon's data is kept

Your clients' names, numbers and appointments sit in one database with a row-level rule per salon. Here is each protection and the mechanism behind it.

What is true, and how

One salon cannot see another's clients
Postgres row-level security, with the policies generated from the schema rather than written by hand, and a test that proves one salon's queries cannot read another's rows.
Card numbers never reach us
Card details go straight to Stripe, which is PCI DSS certified. We store an identifier and the last four digits, never a card number.
Staff sign-in is session-based
Time-limited session cookies that browsers withhold from other sites, an origin allow-list on the API, and a one-time code app for platform operators.
Stored secrets are encrypted
Secrets are encrypted with a key ring, and a deploy stops if the ring is missing rather than starting up unprotected.
The database is not on the internet
Postgres, Redis, object storage and search publish no public port. Only the application containers reach them, over a private network.
Your booking page cannot be flooded
Every public write — booking, contact, gift card, job application — is rate limited, and the human-facing forms also carry a proof-of-work check.

What we have checked

An adversarial internal audit in September 2026 went through authorisation, tenant isolation, input validation, secrets, web hardening, payments and infrastructure. It raised two high-severity findings — an unrated claim-code endpoint and unescaped structured data — and both are fixed and covered by tests.

We hold no SOC 2 report or ISO certificate, and we will not claim one. What is above is what the code does, and a salon can ask us for detail.

Who else processes your data

Found a problem?

Tell us what you found and how to reproduce it. We will reply, fix it and credit you if you want the credit. We will not pursue anyone who reports a problem in good faith.

Report a vulnerability