Trust

Security Overview

Last updated 24 April 2026

Encryption

  • TLS 1.3 in transit for all traffic (automatic via Vercel).
  • AES-256 at rest for database and file storage (Supabase and Google Drive managed encryption).
  • Secrets are injected at runtime from Vercel's encrypted environment — never committed to the repository.

Authentication

  • Passwords stored as bcrypt hashes (cost factor 12).
  • JWT session tokens signed with a rotated secret, HttpOnly, Secure, and SameSite=Lax cookies.
  • Rate limiting on registration, login, and contact endpoints to mitigate credential stuffing and abuse.
  • Role-based access control with five roles (Admin, Account Manager, Team Lead, Employee, Client) enforced at the API layer.
  • Optional Google OAuth sign-in (once activated).

Data isolation

  • Supabase Row-Level Security (RLS) is enabled on all public tables. Clients cannot read rows belonging to other clients; staff access is scoped to role.
  • Service-role keys are kept on the server only and never exposed to client-side code.

Application hardening

  • HTTP security headers: Strict-Transport-Security, X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy locking down camera, microphone, geolocation, and payment APIs we don't use.
  • Content Security Policy restricts script sources and disables inline eval.
  • File uploads are MIME-sniffed, size-capped, and stored outside the application bundle.
  • Prisma ORM with parameterised queries prevents SQL injection.
  • React's default output escaping prevents reflected XSS; we don't use dangerouslySetInnerHTML on user content.

Operational controls

  • All deployments go through Vercel with an immutable build artefact per deployment.
  • Preview deployments for every branch allow review before production.
  • Supabase point-in-time recovery is enabled on the production database.
  • Dependency vulnerabilities scanned regularly; critical patches applied within 7 days.

Incident response

If we detect or are notified of an incident affecting personal data we will:

  1. Contain the issue and preserve evidence.
  2. Notify affected users within 72 hours where required (GDPR Article 33, PIPEDA equivalent).
  3. Report to the relevant supervisory authority where thresholds require it.
  4. Publish a post-mortem summarising cause, impact, and remediation.

Report suspected vulnerabilities to security@broomstickcreative.com. We don't currently run a public bug-bounty programme but we credit responsible disclosures.

Compliance

The Broomstick Hub is built to meet the requirements of GDPR, UK GDPR, and PIPEDA. See our Privacy Policy for full detail on lawful basis, retention, and your rights.

← Back to home