Security / Responsible Disclosure

Last updated: 1 November 2025

Our approach

• Transport security: all traffic served over HTTPS.
• Data at rest: sensitive records are sealed using modern authenticated encryption with per‑record salts and keys derived from a service key (KEK) held in environment secrets.
• Abuse resistance: proof‑of‑work challenge on submission, IP‑based burst limiting, and content moderation with redaction of obvious personal data before any optional external checks.
• Integrity & link security: short‑lived signed links for admin actions and special flows; HMAC signatures on incoming premium/payment webhooks.
• Operational hygiene: minimal, rotating logs; health checks with cached snapshots; admin access optionally gated by Basic Auth and an IP allowlist.
• Security headers: strict Content‑Security‑Policy, X‑Frame‑Options, Referrer‑Policy, X‑Content‑Type‑Options, and a conservative Permissions‑Policy.

Responsible disclosure policy

We welcome good‑faith research and reports that help us protect applicants and recipients. If you follow the rules below, we won’t pursue or support legal action against you for your research.

Rules of engagement

• Do not access, modify, or delete data that isn’t yours. Use test addresses you control.
• Do not disrupt the service. No DoS, rate‑limit exhaustion, automated spam, or brute‑forcing.
• Don’t target third‑party providers (e.g., email infrastructure). Test only via our application.
• No social engineering, phishing, or physical attacks.
• Keep proof‑of‑concepts minimal and avoid sending harmful or illegal content.
• Give us reasonable time to remediate before public disclosure.

Scope

• Production application and all documented endpoints linked from this site, including submission, GDPR deletion, feedback/rating, report‑abuse, premium login, and webhook verification flows.
• Client‑side issues that affect real users (XSS, CSRF, clickjacking where impactful, storage leaks, origin policy issues).
• Server‑side issues (auth/session flaws, access control, injection, logic bugs, insecure direct object references, SSRF, path traversal, crypto misuse).

Out of scope

• Denial‑of‑service or volumetric findings, including PoW/rate‑limit “bypass” that relies on raw traffic.
• Use of leaked or third‑party credentials, or attacks against our email provider itself.
• Best‑practice nits without demonstrated impact (missing headers that are already mitigated elsewhere, informative server banners, generic CSP tightening suggestions).
• Reports that rely on compromised devices, user‑installed malware, or browser extensions.

How to report

Email contactvault@tuta.io with the subject “Vulnerability report.” If you need to share sensitive details, tell us and we’ll provide a PGP key for encrypted follow‑up.

Include clear steps to reproduce, affected endpoints, expected vs. actual behavior, any screenshots or PoC, and the impact assessment. Please add your handle if you’d like public thanks after remediation.

Assessment process & timelines

• Acknowledgement: within 72 hours.
• Triage: initial severity assessment within 7 business days.
• Fix & release: timeline depends on severity and complexity; critical issues are prioritized.
• Credit: with your consent, we’ll add you to a future “Hall of Thanks.” No cash bounties at this time.

Testing tips

• Use your own addresses for sender/recipient. The system supports verification loops and will redact obvious PII in moderation paths.
• Signed links have short TTLs; capture requests quickly and test replay behavior.
• Webhook endpoints require HMAC signatures; validate signature checks and failure modes, but don’t send traffic from other people’s accounts.
• Evaluate CSP and frame protections on dynamic pages; static policy pages may intentionally allow fewer features.

Thanks for helping us keep applicants safe.