ContactVault Logo ContactVault ALPHA v.1.0

Security at ContactVault

Architecture at a glance

High-level flow of data through the current ContactVault applicant-side mail system.

Client (Applicant) TLS • CSP‑hardened UI Application Flow Verify • Rate limits • Moderation Mail Runtime Outbound mail • Reply mailbox Encrypted Message Store XChaCha20‑Poly1305 • HKDF Signed Links & Sessions HMAC • TTL • Replay block Inbound Reply Intake Mailgun signatures • Anti-replay Employer Inbox

Modern encryption end to end

All sensitive payloads are sealed using an authenticated cipher (XChaCha20‑Poly1305) and keys derived with HKDF‑SHA256. Each record receives its own random salt and nonce, giving strong confidentiality and integrity.

  • Per‑message keys and nonces to prevent reuse.
  • Constant‑time comparisons to resist timing leaks.

Anonymity by design

Employers do not see an applicant’s personal email address by default. ContactVault issues mailbox addresses on the applicant side so first contact and replies can happen without exposing the applicant’s personal inbox.

  • Dedicated ContactVault mailbox addresses keep applicant identity separated from personal contact details.
  • Structured outcome buttons and ordinary replies both stay inside the employer’s own email client.

Signed links with short lifetimes

Verification links, applicant login links, and sensitive actions are protected with HMAC signatures, embedded nonces, and explicit expiration. Tokens are verified on every use and marked as consumed to prevent reuse.

Abuse‑resistant by default

Public entry points enforce burst limits, daily quotas, email/IP throttles, and optional proof-of-work to slow down automated abuse without penalizing normal applicants.

  • Per-IP throttling for public send and applicant-login hot paths.
  • Configurable proof-of-work gate for public forms.

Minimal retention, clear lifecycle

Operational data is stored only as long as needed to deliver messages, receive replies, support applicant access, and prevent abuse. Retention jobs clean up automatically so old data does not linger.

Hardened web surface

Strict defaults are shipped for common web risks.

  • Public traffic terminates at Apache reverse proxy; the app process is bound to localhost only.
  • Content Security Policy and frame protections.
  • HSTS and secure cookies where applicable, including strict applicant-session cookies.
  • Server‑side input validation and templating with auto‑escaping.

Operational safeguards

Detailed audit logging, health checks, and alert thresholds help us detect anomalies fast. Outbound email is validated and sensitive fields are redacted in logs.

  • Mutable runtime data is isolated outside the app code directory.
  • The applicant mail runtime is isolated from the public app surface behind the reverse proxy.
  • Daily automated checks monitor config drift and critical path health.

Responsible disclosure

If you believe you’ve found a security issue, please use our responsible disclosure channel. We review reports quickly and appreciate coordinated fixes.

What’s next

  • Remove remaining debug-only auth surfaces before production cutover.
  • Add CSRF protection before introducing new authenticated browser-side write flows on `/v2`.
  • Expand continuous tests and monitoring around login issuance, inbound mail, and abuse-report flows.

These are incremental upgrades on top of a security model already centered on applicant-controlled communication.