Security at Clearbox

You trust Clearbox with access to your email. We take that trust seriously. Here is exactly how we protect your data.

Independent security audit passed April 12, 2026
0
Critical issues
0
High issues
AES-256
Encryption standard
0
Known CVEs

Authentication & Sessions

  • HMAC-signed session tokens with timing-safe verification — your session cannot be forged or tampered with
  • Session tokens are hashed (SHA-256) before database storage — even a database breach cannot reveal active sessions
  • Server-side session validation on every API request via Next.js middleware
  • Sessions are invalidated on logout and can be revoked globally for security events
  • OAuth login via Google with server-side nonce verification to prevent cross-site request forgery (CSRF)
  • One-time-use OAuth state tokens with 10-minute expiry, stored server-side

Encryption

  • AES-256-GCM encryption for all sensitive data at rest — OAuth tokens, email content, subjects, and sender information
  • Per-user encryption keys derived using HKDF-SHA256 — each user’s data is encrypted with a unique key
  • Encryption salt is a required environment variable — never hardcoded, never committed to source control
  • Authenticated encryption (GCM) ensures data integrity — tampered ciphertext is detected and rejected
  • HTTPS enforced everywhere with HSTS (Strict-Transport-Security) headers

Data Isolation

  • Every database query is scoped by authenticated user ID — one user can never access another’s data
  • Row-Level Security (RLS) enabled on all database tables as an additional enforcement layer
  • Gmail API calls use per-user OAuth tokens scoped to the authenticated session
  • Background sync jobs propagate user context correctly — no cross-user data mixing
  • Complete data cleanup when disconnecting an account — tokens, cache, history, and logs are all purged

API Security

  • CSRF protection on all destructive endpoints via Origin header verification
  • SSRF protection on all URL-fetching operations — private IPs, localhost, and internal ranges are blocked via DNS resolution checks
  • Generic error messages returned to clients — internal details are logged server-side only, never exposed
  • Input sanitization on email headers to prevent header injection attacks
  • Field-level whitelisting on update endpoints to prevent unauthorized column modification
  • Admin endpoints protected by server-side password verification with timing-safe comparison

OAuth & Gmail Permissions

  • Least-privilege Gmail scopes: gmail.modify and gmail.readonly — no permanent delete capability
  • OAuth refresh tokens encrypted at rest with per-user AES-256-GCM keys
  • Tokens are revoked at Google when you disconnect an account — we don’t retain access
  • Access tokens are short-lived and automatically refreshed with a 5-minute buffer
  • Clearbox never stores your Google password — authentication is handled entirely by Google’s OAuth

Infrastructure

  • Deployed on Netlify with automatic HTTPS and edge-level TLS termination
  • All secrets stored in environment variables — never in source code or version control
  • Security headers enforced: X-Frame-Options (DENY), X-Content-Type-Options (nosniff), Referrer-Policy, Permissions-Policy
  • Zero known vulnerabilities in dependencies (npm audit clean)
  • .env files excluded from version control via .gitignore — verified across full git history
  • Background jobs (cron) protected by bearer token authentication

Responsible Disclosure

If you discover a security vulnerability, please report it to us privately so we can address it before public disclosure. Contact us at chananzlot@gmail.com. We aim to acknowledge reports within 24 hours and resolve critical issues within 72 hours.

Last audited: April 12, 2026· Audit scope: full codebase review (OAuth, encryption, API routes, data isolation, infrastructure)

Back to Clearbox