SECURITY POLICY

Last Updated: August 7, 2026

NOVA Mail takes the security of your data seriously. This document describes our actual security architecture, controls, and vulnerability disclosure program. It is updated whenever the implementation changes.

1. SECURITY ARCHITECTURE

1.1 Encryption at Rest

Message bodies are encrypted at rest with AES-256-GCM (256-bit keys, Galois/Counter Mode, authenticated encryption):

• Every message receives a unique 96-bit initialization vector (IV) — no two messages share an IV
• The body encryption key is held as a Cloudflare secret (ENCRYPTION_KEY), never in the database or source code
• Bodies are decrypted by the service when you read them (same model as Gmail, Outlook, and other mainstream providers)

NOVA-to-NOVA email (end-to-end encrypted): when both sender and recipient are NOVA users, messages are additionally encrypted with end-to-end encryption — encrypted to the recipient's public key on the sender's device, stored as e2e_body, decrypted only on the recipient's device. The server stores only encrypted ciphertext and can never decrypt e2e-encrypted messages. Account key pairs are generated on registration; private keys are encrypted with a key derived from your password (PBKDF2-HMAC-SHA-512, 100,000 iterations) and we hold only the encrypted private key.

Attachments are encrypted at rest with envelope encryption:

• Each attachment gets its own random 256-bit Data Encryption Key (DEK) used with AES-256-GCM
• The DEK is wrapped (encrypted) by a Key Encryption Key (KEK) derived from the ATTACHMENT_KEK Cloudflare secret
• Only the wrapped DEK (stored with the attachment row) and the ciphertext persist — the raw DEK is never stored
• On download, the plaintext is re-hashed and compared against the stored SHA-256 to detect tampering or corruption (authenticated decryption would already fail on tampering; the hash is a second layer)

Email metadata (subject, sender, recipient, timestamp) is not encrypted because search and folder organization depend on it. It is stored with strict access controls and never shared.

1.2 Encryption in Transit

• All web traffic uses TLS 1.3 terminated by Cloudflare
• Outbound delivery to external mail servers uses STARTTLS where the receiving server supports it
• SPF, DKIM, and DMARC records are configured for nova-email.com

1.3 Password Security

Property	Specification
Algorithm	**Argon2id** (memory-hard)
Parameters	**m=64 MiB, t=3 iterations, p=1** — OWASP 2026 recommended configuration (~350 ms/hash)
Salt	128-bit cryptographically random, unique per user
Storage	Hash only — plaintext never written to disk or transmitted after registration
Upgrade	Accounts created before the Argon2id migration authenticate with PBKDF2-HMAC-SHA-512 (100,000 iterations) and are transparently upgraded to Argon2id on their next successful login. Argon2id hashes with weaker parameters are rehashed to the current parameters on next login

1.4 Authentication Security

• Two-factor authentication (TOTP): RFC 6238 6-digit codes from any standard authenticator app, verified against a per-user secret stored hashed-side-channel-safe (constant-time comparison)
• Recovery codes: 10 one-time codes, stored as salted SHA-256 hashes, regenerable from Account settings
• Passkeys (WebAuthn): FIDO2/WebAuthn sign-in with platform or cross-platform authenticators; challenge replay protection, credential counter rollback detection, signature verification against stored COSE public keys
• MFA-gated logins: when 2FA is enabled, a login issues a short-lived pending session; the real session is only issued after the code/recovery key verifies
• Brute-force protection: failed login attempts are rate-limited per IP address and per account (5 failures per 5-minute window → 429). A successful login records the attempt
• Rate limiting: 20 outbound messages per 60 seconds per user; login attempts as above
• Session tokens: random 256-bit tokens, 24-hour expiration, revocable from Account settings (including "revoke all"), audited on sign-in/revocation. Sessions are recorded with IP, user agent, device name, and last-seen time; a login-alert email is sent on first sign-in from a new device
• Login audit log: every authentication event (login, failed login, 2FA step, passkey sign-in, logout, session revocation, password change, recovery-code use) is written to an audit log you can review in Account settings

1.5 API Security

• Authentication: all API routes require a bearer session token except public endpoints (login, register, recovery, report)
• Rate limiting: outbound sending (20/min per user) and login attempts are enforced server-side
• Security headers: API responses include X-Content-Type-Options: nosniff, X-Frame-Options: DENY, and appropriate referrer/CSP headers
• HTML sanitization: message HTML is sanitized before rendering in the app (strips scripts, iframes, event handlers, and javascript: URLs); HTML is stored but never executed by the app
• File-type blocking: .exe and .msi attachments are rejected at send time

1.6 Infrastructure Security

Layer	Measure
Network	Cloudflare DDoS protection, WAF, SSL/TLS termination
Compute	Cloudflare Workers/Pages Functions — ephemeral, no persistent disk, no shell access
Database	Cloudflare D1 — encrypted at rest by Cloudflare, access-controlled via API tokens; sensitive columns additionally encrypted at the application layer
Email	Cloudflare Email Routing — DKIM, SPF, DMARC configured
Secrets	Cloudflare Secrets — encryption keys (`ENCRYPTION_KEY`, `ATTACHMENT_KEK`), never in the database or repository

2. VULNERABILITY DISCLOSURE PROGRAM

NOVA Mail welcomes security research and responsible disclosure.

2.1 Scope

• The NOVA Mail web application (nova-email.com and all subdomains)
• The NOVA Mail API endpoints
• The NOVA Mail email infrastructure

2.2 Out of Scope

• Physical attacks, social engineering, or phishing of NOVA Mail personnel
• Denial of service attacks
• Attacks requiring physical access to a user's device
• Vulnerabilities in third-party services (Cloudflare, etc.)
• Previously reported or known vulnerabilities

2.3 Reporting Vulnerabilities

Report to [email protected] with:

1. A clear description of the vulnerability
2. Steps to reproduce
3. Potential impact
4. Suggested remediation

Do NOT: publicly disclose before we have addressed it; access or modify user data beyond what is necessary; use automated scanners without prior authorization.

2.4 Our Commitment

1. Acknowledge receipt within 48 hours
2. Initial assessment within 5 business days
3. Remediation target: critical 14 days, high 30 days
4. Notification when the fix is deployed
5. Credit in our security acknowledgments (or anonymous)

2.5 Safe Harbor

NOVA Mail will not pursue legal action against researchers who report vulnerabilities in accordance with this policy, act in good faith, and do not exploit vulnerabilities beyond what is necessary to demonstrate them.

3. INCIDENT RESPONSE

1. Detection & Triage: monitoring alerts; initial assessment as soon as possible after detection
2. Containment: affected systems isolated; access revoked if credentials compromised
3. Investigation: root cause analysis; forensic data preserved
4. Notification: affected users notified as required by applicable law (GDPR: within 72 hours where applicable), with nature of breach, data affected, steps taken
5. Remediation: fix deployed; post-mortem conducted; controls improved

4. ACKNOWLEDGMENTS

None yet — be the first.

---

Report vulnerabilities: [email protected] Security inquiries: [email protected]

© 2026 NOVA Mail. All rights reserved.