Security Policy

ScopeHunter — professional & trust network for security practitioners

ScopeHunter is built for security professionals, which means we hold ourselves to a higher bar than "trust us." This page describes how we handle vulnerability reports, what we actually do to protect your account and data, and where our current gaps are — stated plainly rather than glossed over.

Reporting a vulnerability

If you believe you've found a security issue in ScopeHunter, we want to hear about it before anyone else does. Email security@scopehunter.io with as much detail as you can provide: the affected endpoint or feature, steps to reproduce, and the impact you believe it has. Please do not open a public GitHub issue for anything that hasn't already been fixed.

Safe harbor

We will not pursue legal action against, or report to law enforcement, anyone who makes a good-faith effort to comply with this policy. Good faith means:

• Testing only against your own account(s) — never accessing, modifying, or exfiltrating another user's data.
• Reporting a finding promptly and not disclosing it publicly before we've had a reasonable opportunity to address it.
• Avoiding actions that degrade service for other users — no automated scanning at volume, no denial-of-service testing.
• Not exploiting a finding beyond what's needed to demonstrate it.

Scope

In scope: scopehunter.io and its subdomains, and the API/auth services they talk to.

Out of scope:

• Denial-of-service or resource-exhaustion testing.
• Social engineering, phishing, or physical attacks against staff.
• Automated vulnerability scanners run without rate limiting.
• Findings that require a jailbroken/rooted device or a compromised browser to exploit.
• Missing security headers or best-practice hardening with no demonstrated, concrete impact.
• Reports generated primarily by an AI tool without independent verification that the finding is real and exploitable.

How we protect your account

• Two-factor authentication. TOTP-based MFA is available on every account, and enforced at the session level — an MFA-enrolled account cannot use a password-only session for authenticated requests.
• No passwords stored in our database. Authentication is handled by a dedicated, self-hosted auth service (Supabase Auth / GoTrue) with its own isolated database role; the application backend never sees or stores raw passwords.
• Google sign-in is available as an alternative to a password.
• Every connection to the site is encrypted. Plain HTTP requests are redirected to HTTPS; there is no unencrypted path to or from the site.
• Login rate limiting. Repeated sign-in attempts are throttled at the edge (nginx) — unlimited password guessing against an account isn't possible.

How we protect your data

• Least-privilege database access. The application, the auth service, and each backend component connect to the database as separate, narrowly-scoped roles — no shared superuser access for day-to-day operation.
• Authorization by construction, not by convention. Profile edits go through an explicit allow-list of writable fields; there is no code path where a user can set their own trust score, verification status, or account type.
• Ghost Mode. Accounts can opt out of analytics tracking and activity visibility entirely.
• Consent-gated analytics. Analytics scripts do not load at all until you explicitly opt in.
• Data export and deletion. Account data export and deletion requests are tracked end-to-end (not a one-off manual process), and a deleted account's identifying data is purged while historical content it's referenced from (like a reply in someone else's thread) remains structurally intact but disassociated.
• We don't store raw identity documents. Identity verification is designed around a third-party attestation model — the underlying documents/selfies used for verification are never persisted in our own database.

Where we're not there yet

In the interest of not overstating our posture: there's no dedicated WAF in front of the site yet — nginx-level rate limiting on the login endpoint covers brute-force attempts, but a WAF would add broader protection against a wider range of request-level attacks — and this is a young platform that hasn't yet been through an independent third-party security audit. None of this is hidden from anyone who reads our source — ScopeHunter's backend and infrastructure automation are open about their current state by design.

Last updated: 2026-08-09. This policy is also published in machine-readable form at /.well-known/security.txt (RFC 9116).