Security

Reporting a vulnerability

Email security@controlverdict.com. Include a description, affected URLs or code paths, and reproduction steps.

• We aim to acknowledge within 3 business days.
• Please do not open a public issue for a suspected vulnerability.
• Please do not test against other people’s accounts or content. If you need an account for testing, ask and we will provide one.
• We do not currently run a paid bounty. We will credit you in the release notes if you want.

What is in scope

The application, its database schema, authentication and session handling, authorization checks, the sanitization pipeline, and the deployment configuration in the public repository.

Out of scope: reports whose only content is a scanner’s output, missing headers with no demonstrated impact, denial of service by volume, social engineering of moderators, and the absence of features (for example, “there is no 2FA on the magic link”).

How accounts are protected

• Passwordless sign-in. Single-use email magic links (optional OAuth with narrow scopes). There is no password database to breach and nothing to reuse from another site.
• Database sessions, not JWTs. A ban or sign-out revokes access at the next request instead of at token expiry.
• Session cookies are httpOnly and sameSite=lax, and secure when the site is served over HTTPS.
• No account enumeration on sign-in. The form never reveals whether an address is already registered — membership here is itself sensitive.
• Roles are read fresh from the database on every request. Promotions, demotions, and bans take effect immediately. Assessor vote weight requires both the assessor role and an administrator-recorded verification.

How content is protected

• Every write is validated with a schema before it touches the database. Text is normalized to strip control characters and bidirectional overrides.
• User markdown is rendered through a sanitizing pipeline that admits no raw HTML and allow-lists what may appear. Unsafe tags and URL schemes are stripped.
• A Content Security Policy with a per-request nonce and strict-dynamic blocks injected scripts. There are no third-party analytics or advertising scripts.
• Mutations go through Server Actions with Origin checks. Sign-out is a POST, not a link, so a cross-site image cannot log you out.
• Write paths are rate limited. Sign-in attempts from anonymous clients are keyed by an HMAC of the network address so the raw address is not stored.

Hosting and assurance

ControlVerdict runs on a commercial application platform that publishes SOC 2 Type 2 and ISO/IEC 27001 attestations for its own infrastructure and operations. Those reports cover the host — not this product. Using a certified platform does not mean ControlVerdict inherits that certification, and we do not claim SOC 2 or ISO 27001 for the application itself.

Separately, we treat the source and the running system as our responsibility: the code and implementation receive regular security review (including automated checks and focused human review on auth, sessions, and authorization), and we schedule penetration testing / equivalent independent assessment against the public surface. Findings are tracked to remediation; known limitations and operator controls are documented in the repository’s SECURITY.md.

Data minimization

• Email addresses are visible only to administrators. Public identity is a handle you choose.
• Assessor credential references recorded during verification are admin-only and never rendered elsewhere.
• Moderated content is soft-deleted so a mistake can be undone and a discussion keeps its structure. Privileged actions are written to an append-only audit log in the same transaction as the change.

Your responsibility when posting

Automated checks and human review reduce risk; they do not replace author judgement. Never post CUI, client names, real hostnames, addresses, or anything that identifies a specific environment. Describe the pattern, not the deployment. See About for posting rules and how verdicts work.