ChairUp Security & Coherence Audit
The verdict
Health score 0.70 / 1.0No critical vulnerability, and no evidence of a breach.
ChairUp has a sound security foundation — and we verified it on a running system rather than reading it only in source. The issues that remain concern data exposure, not the access locks themselves, and every one is listed in the action plan, worst-first.
Scope: who can reach what data · the payment & escrow path · how closely the build matches intent · performance & quality. A focused review, not a line-by-line audit of every component.
Launch readiness
9 findings · 3 priority · 4 verified strongThe access foundation is verified on the running system — database rules enforced, the privilege-escalation barrier holds, no factory-default secret in use. Findings by disposition:
Findings map
Each tile is one finding — click to jump to itWhat we reviewed
Verified against a faithful reconstructionThe action plan
One job each · ordered worst-firstFindings in full
Security lens — what runs vs what shouldProduct lens
0.81 · does what was built match what was meant?ChairUp never had a written specification, so we reconstructed intent from the original build conversation and measured what got built against the running system. The six core promises:
A note on naming & pricing drift
During development the product was renamed more than once, and an older web address still lingers in the code and in the stray page above — worth tidying so everything matches the current brand. The pricing model was also simplified along the way (an earlier paid membership was dropped); any leftover wording referring to the old paid tier should be removed.
User experience & functional issues
Hands-on use surfaced these functional issues. None affects data security; each affects whether new users complete sign-up cleanly. Address them with the should-do items before launch.
- Onboarding does not save progress between pages. Information entered on one step can be lost when moving to the next. Each step should be saved as the user advances.
- Onboarding does not enforce required fields per page. Mandatory fields are validated only at the final step, if at all, allowing incomplete profiles. Validation should run as each page is completed.
- "Browse shops" from a barber profile leads to the wrong page. It navigates to the "list chairs" page instead of the intended destination.
- First and last name are not retained after sign-up. A name entered during registration does not appear on the Settings page afterward, suggesting it is not persisted to the profile.
Method & scope
How we audited · verified, not just scannedMost reviews tell you what the code says. We measure how well three things line up — and where they diverge, that gap is the work.
Intent
What ChairUp was meant to do.
Belief
What the code and its configuration think they do.
Reality
What the running system actually does when you push on it.
Candidates from tooling, conclusions from the running system
Automated tooling reads source one statement at a time and can miss a later change that corrects an earlier line. We treat it as a source of candidates only. Every finding was checked against a running copy of the system — a faithful reconstruction of ChairUp's database, assembled from the project's own setup steps.
Confirmed identical — 43 / 43 checks
The reconstruction was confirmed identical through an automated rebuild that passed all 43 of its checks. We read it as the system’s true final state, not a guess. This overturned three tool-flagged "defects": public profile views are correctly per-viewer scoped, email-function hardening is present in the final state, and the database rebuilds cleanly.
Deliberate about confidence
A concern only counts against the score when the system is confident about something the running code contradicts. Where a step genuinely requires an action a read-only review cannot take — moving a test payment — we say so and recommend it, rather than inflate a score for something we haven’t observed.
Read-only, no money moved
No production data was changed and no real payment was run — the money path is deliberately left for a human-authorised test. Verification was read-only apart from one synthetic test sign-up created to prove the access rules (flagged for cleanup).
Database access rules are genuinely enforced; a user who labels themselves "admin" reaches no privileged data; no factory-default secret is in use; the database rebuilds cleanly; and no hidden administrator account is created during setup. The dispute and no-show machinery is fully built — a dispute lifecycle, an admin queue, escrow that skips disputed bookings, and account freezes on failed payments.
The hosting platform does not expose ChairUp's live production database for direct inspection, so live results are established against the faithful reconstruction rather than production itself. The two are built from the same code and should match; what we cannot see is any setting changed directly in the production hosting dashboard and never committed to the project's code. We name this as a known limitation rather than claim coverage we do not have.
Recommendations
Restrict the server-only payment identifiers so they are not returned to the client, keeping the user-visible money figures.
Restrict columns at the DB · verify no screen depends on themLock down the privileged database function reachable by unauthenticated callers.
Withdraw public execute · add a caller check or restrict to serverStop exposing chair listings to the public. Gate visibility behind sign-in; release identifying details only on an accepted application.
Validate the full money path once with an authorised test-mode transaction: charge → held in escrow → released → balance credited, fee split matching.
One authorised test-mode transactionNo critical vulnerability. No evidence of a breach.
ChairUp has the foundation right, established on a running system rather than only read in source. The remaining work — the data-exposure fixes, the function lockdown, the listing-visibility change, and an authorised money-path test — is set out in the action plan, ordered by priority.