Responsible Disclosure

How to report

• What the issue is, and what an attacker could achieve with it.
• Step-by-step reproduction, including exact URLs and any required input.
• Browser and operating system, if relevant.
• Proof-of-concept code or a screenshot, where that makes the issue clearer.
• How you would like to be credited, if we publish a fix note.

What we commit to

• Acknowledgement within 5 business days that a human has read your report.
• An initial assessment within 10 business days, telling you whether we consider it valid and roughly how we intend to handle it.
• Progress updates at least every 14 days while a confirmed issue is open.
• Credit in any public fix note, if you want it. We will use whatever name or handle you specify, or none.
• No legal action against researchers who follow this policy in good faith.

Scope

In scope

• The web application at our canonical domain and all its subpaths.
• The API endpoints backing note storage, retrieval and sharing.
• The client-side cryptographic implementation — key derivation, encryption, randomness handling.
• Authentication and authorisation logic around share tokens, expiry and view limits.
• Anything that would let a party without the password recover note plaintext.
• Anything that would let one user access, modify or delete another user's note.

Out of scope

• Findings from automated scanners submitted without a demonstrated impact.
• Missing security headers with no accompanying exploit path.
• Absent rate limiting on endpoints where it has no security consequence.
• Social engineering of our team or our users.
• Denial of service, including volumetric and resource-exhaustion attacks.
• Issues in third-party services we depend on — please report those to the vendor.
• The known limitations we already document, including that we serve the code performing encryption and that weak passwords are guessable offline. These are stated in the threat model and are design trade-offs rather than defects.

Rules of engagement

1. Only test against notes you created yourself. Do not attempt to access anyone else's data.
2. Do not run destructive tests. No deletion of data you do not own, no attempts to degrade availability.
3. Stop at proof. Once you have demonstrated an issue exists, stop — do not enumerate how much data is reachable.
4. Do not exfiltrate data. If you inadvertently access someone else's content, stop, do not retain it, and tell us immediately.
5. Give us reasonable time before publishing. 90 days from acknowledgement is our default; if we need longer we will explain why and agree a date with you.

Disclosure timeline

1. 1

   Day 0 — You report

   Email to work.securetext@gmail.com.
2. 2

   Within 5 business days — We acknowledge

   Confirmation that a person has read it, plus any clarifying questions.
3. 3

   Within 10 business days — Initial assessment

   Whether we consider it valid, our severity assessment, and an indication of timeline.
4. 4

   Ongoing — Remediation

   Updates at least every 14 days. Critical issues are worked on immediately; lower-severity issues are scheduled and we tell you when.
5. 5

   By day 90 — Public disclosure

   We publish a note on the changelog once a fix ships, with credit if you want it. If more time is genuinely needed, we will say why and agree a revised date rather than going quiet.

Rewards