ChessViewer is a web application — only the code running at chessvision.org is actively maintained. There are no versioned releases; the master branch is always the current production deployment. Self-hosted deployments should track master.

All board rendering and image export runs in the browser. No position data is sent to any server during normal use.

• No analytics, cookies, or telemetry
• FEN input is length-capped at 93 characters before any parsing attempt
• All localStorage and Supabase response parsing uses safeJSONParse to prevent prototype pollution
• FEN strings and hex colours are sanitized at input boundaries (sanitizeInput, sanitizeHexColor)

Users may sign in to enable cross-device sync. When cloud sync is active:

• Data is stored in Supabase with row-level security (RLS) enforced on every table — rows are scoped to the authenticated user; one account cannot read another's data
• Privileged operations (e.g., security session reset) use an RPC function rather than direct table writes, so the application cannot bypass the server-side policy
• The local localStorage copy is the source of truth; cloud is best-effort sync on top

• Email/password with optional TOTP-based multi-factor authentication via Supabase
• A 90-day re-verification gate is enforced for sensitive operations (useSecurityCheck) — it defaults to locked and only unlocks on positive server confirmation
• No custom TOTP logic; the standard Supabase MFA flow is used throughout

• Content Security Policy (CSP) prevents XSS and unauthorized script execution
• HTTPS with HSTS enforced on deployment
• No inline scripts; all logic is bundled from verified sources
• target="_blank" links always include rel="noopener noreferrer"

Do not open a public GitHub issue for security vulnerabilities.

1. Go to the Security tab.
2. Click "Report a vulnerability".
3. Fill in the advisory form.

Send to: contact@chessvision.org
Subject: [SECURITY] <brief description>

• Type of vulnerability (XSS, injection, authentication bypass, etc.)
• Steps to reproduce
• Potential impact
• Proof of concept, if available

• Initial acknowledgment: within 48 hours
• Fix development: typically 5–10 business days depending on severity
• Public disclosure: after a fix is released (coordinated disclosure)

Dependencies are monitored via Dependabot. Run pnpm audit locally to check for known vulnerabilities.

Last updated: June 2026