Security at SnitchHQ
SnitchHQ is built for multi-tenant use inside real companies, so security isn't a feature we bolted on — it's enforced at the lowest layer we control: the database. Here's exactly how your data is protected, in plain language.
Tenant isolation, enforced by the database
Every organization's rooms, reports, and team live behind Postgres row-level security. Isolation is enforced by the database engine itself — not just our application code — so one customer can never read or change another's data, even if a bug slipped past the app layer.
Role-based access, also in the database
Owners, admins, technicians, and viewers each get exactly the permissions their role allows. Roles are checked on the server and enforced again by per-command database policies, and a database trigger blocks anyone from escalating their own role.
Passwordless sign-in
Team members sign in with one-time email links. We never store passwords, so there are no passwords to leak, phish, or reuse from another breach.
Anonymous, tracker-free reporting
Reporters never create accounts and never touch the database directly — the scan page carries no cookies, no analytics, and no third-party beacons of any kind. Submissions flow through narrow, purpose-built endpoints with no other access.
Data minimization by default
We collect the minimum to route a fix: the room, the issue, and an optional note or photo. Photos are stripped of hidden metadata (like GPS) before storage, and reporter IPs are only ever kept as irreversible one-way hashes used for rate-limiting.
Encryption & private storage
All traffic is encrypted in transit with HTTPS/TLS, and data is encrypted at rest by our infrastructure providers. Report photos live in private storage and are served only to signed-in members of the owning organization, from our own domain.
Hardening we've done
- Per-command database policies: reads, inserts, updates, and deletes are each authorized separately per role — no blanket write access anywhere.
- A database trigger blocks self-service privilege escalation: no user can change their own role or move themselves between organizations.
- Outbound webhooks (Slack / Teams) are validated against SSRF: HTTPS only, with private, loopback, and cloud-metadata addresses rejected at creation and at send time.
- CSV exports neutralize spreadsheet formula injection, so a malicious report note can't execute when a manager opens the export in Excel.
- Internal security review (July 2026): tenant isolation and the role model were tested against the live database, including attempted privilege escalation with member-level credentials.
Infrastructure
SnitchHQ runs on a deliberately small set of established providers, each of which maintains SOC 2 attestations for their platforms:
- Vercel — application hosting and delivery
- Supabase — database, authentication, and file storage (hosted in the US)
- Resend — transactional email delivery
- Cloudflare — DNS and network protection
Fewer moving parts means a smaller attack surface — and a shorter list for your vendor-review team.
What's next
As we grow with larger customers, our roadmap includes an external third-party penetration test, a SOC 2 audit of our own, SSO (SAML / OIDC), and a customer-facing audit log. If your security team has a questionnaire or specific requirements, we're happy to work through it.
Reporting a vulnerability
Found something? We welcome good-faith security research and will respond quickly. Email [email protected] with details and we'll take it from there. Please don't access data that isn't yours — a proof of concept against your own workspace is plenty.
This page describes our current practices and is updated as they evolve. For what data we collect and why, see the Privacy Policy.