Vulnerability Disclosure Policy

1. Our commitment

We take security seriously. If you have found what you believe to be a security vulnerability in the Service, we want to know about it and we want to fix it. This policy describes how to report, what we commit to in return, and the boundaries within which good-faith research is welcome.

2. Safe harbor

We will not pursue legal action against security researchers who act in good faith and within the rules of this policy. Specifically, we will:

Not contact law enforcement about your research.
Not bring civil claims under the CFAA, DMCA anti-circumvention provisions, or similar laws in other jurisdictions.
Not interfere with you exercising reasonable coordinated disclosure after we have had a chance to remediate.

If legal action is initiated by a third party against you for activities that complied with this policy, we will make clear publicly that the activities were authorized.

To qualify for this safe harbor you must:

Stay within the scope in §4.
Not cause harm (see §5).
Report privately (see §6) and give us a reasonable window to fix the issue before any public disclosure.
Not access, modify, or exfiltrate personal data beyond the minimum needed to demonstrate the vulnerability.

3. How to report

Email: security@theaccessible.org.
Encryption: our submission inbox is monitored over TLS. If you prefer to encrypt a report end-to-end, mention that in your first message and we will coordinate a secure channel.
Response SLA: we acknowledge every report within 2 business days and provide an initial triage outcome within 10 business days. Remediation timelines depend on severity — see §8.

4. Scope

4.1 In scope

theaccessible.org, www.theaccessible.org, and subdomains (api-pdf, api, pdf, legal, help, etc.) that we own and operate.
Our mobile and desktop clients, if any, that we distribute.
Our public API endpoints.

4.2 Out of scope

Third-party services we link to or embed (Cloudflare, Supabase, Stripe, AI providers). Report those to the vendor directly.
Social-engineering attacks against our staff or customers.
Physical attacks against our offices or infrastructure.
Denial-of-service attacks (see §5).
Findings that depend on a compromised user device or browser extension we don't distribute.
Reports generated solely by automated scanners without a clear exploitation path.

4.3 Specifically not a vulnerability

Missing security headers on pages that don't hold personal data, where the absence has no exploitability.
TLS configuration differences that meet our published minimums.
Disclosure of framework or server banners without an exploitable consequence.

5. Avoid harm

Do not:

Access, modify, or destroy data belonging to anyone other than you or a test account you create.
Run denial-of-service tests, load testing, or brute-force credential attacks.
Spam, phish, or socially-engineer our personnel or users.
Violate applicable law.
Publicly disclose before we have had time to fix the issue (see §8).

If you accidentally access data beyond what's needed for the proof-of- concept, stop, do not retain it, and tell us what happened.

6. What to include in a report

Please include enough information for us to reproduce:

Affected URL, endpoint, or component.
Step-by-step reproduction instructions.
Proof-of-concept (video, screenshot, request/response pairs) where appropriate.
Impact you believe this could have (what an attacker could do).
Your preferred contact address and any public credit preferences for §9.

7. Our severity scale

We use a simplified CVSS-inspired scale for prioritization and remediation timelines. This is informational and not a commitment.

Severity	Example	Target remediation
Critical	Remote code execution, mass data exfiltration	24 hours to mitigate, patch within 7 days
High	Vertical privilege escalation, authenticated access to other users' data	7 days
Medium	Business-logic bypass with limited impact, stored XSS in authenticated areas	30 days
Low	Self-XSS, reflected XSS requiring user interaction, information disclosure of non-sensitive data	90 days or next regular release

8. Coordinated disclosure

We ask you not to publish details until:

We have deployed a fix, or
90 days have passed since your report, whichever is earlier.

If a fix requires more time and we are actively working on it, we will discuss an extension with you. We want to credit your work, not suppress it.

9. Recognition

With your permission, we will acknowledge your report publicly (on this page and/or in release notes) once the issue is remediated. Include your preferred handle and a link (personal site, GitHub, LinkedIn) in the report.

We do not currently operate a paid bug-bounty program. If that changes, we will update this page at least 30 days in advance. Any ex-gratia rewards are at our discretion and are not a commitment.

10. Legal

This policy does not authorize, and this safe harbor does not apply to:

Any activity outside the scope in §4.
Attacks against third parties.
Violations of any law we are bound by, or that you are bound by in your jurisdiction.

If any part of this policy conflicts with applicable law, that part is severed; the rest continues in force.

11. Changes

We will update this policy as our posture matures. The effective date appears at the top of this page. Prior versions remain available from the version history link below.

12. Contact

Reports: security@theaccessible.org
Other security questions: security@theaccessible.org
Media / press: do not include sensitive report details in media inquiries; write to security@theaccessible.org first.

Our general security posture is described in the Security Overview.