Contact Vault Logo Contact Vault ALPHA v.1.3

Security at Contact Vault

Architecture at a glance

High-level flow of data through the current Contact Vault 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. Contact Vault issues mailbox addresses on the applicant side so first contact and replies can happen without exposing the applicant’s personal inbox.

  • Dedicated Contact Vault 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.

A smaller first-contact layer

The GDPR data-minimization principle requires personal data to be adequate, relevant, and limited to what is necessary for its purpose. European Data Protection Supervisor guidance similarly warns that recruitment forms should not collect more personal information than necessary.

Contact Vault is designed around a smaller first-contact layer: applicants can send a focused message and structured résumé summary without exposing their personal email address by default. This design choice supports data minimization, but it is not a claim that every use of the service is automatically GDPR-compliant.

Sources: GDPR Article 5(1)(c); EDPS recruitment guidance.

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.

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.

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.

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.