Vulnerability Disclosure / Responsible Disclosure Policy

In-Scope

Researchers may submit vulnerabilities in our systems and services under the following constraints:

• Web applications, APIs, backend services, and systems under our control
• Code, logic, authentication, access control, encryption, and data flows
• Configurations, integrations, and dependencies directly managed by us

If you are unsure whether a target is within scope, please contact us before proceeding.

Out-of-Scope

The following are not eligible or are explicitly disallowed:

• Issues in third-party services, infrastructure, or software outside our direct control
• Social engineering (e.g. phishing, vishing), physical attacks, or human manipulation
• Denial-of-service (DoS) or volumetric attacks causing service disruption
• Automated scanning of all endpoints without a proof-of-concept or context
• "Theoretical" vulnerabilities without any exploit path or reproduction
• Issues affecting deprecated systems no longer in use
• Weaknesses in client-side code not under our control (e.g. browser extensions we don't maintain)
• Attacks requiring hardware access

1. Do no harm

• Avoid disruption to services, performance degradation, or undue load
• Do not delete, modify, or destroy data
• Do not attempt to access, download, or exfiltrate more data than needed to demonstrate the vulnerability

2. Limit data access

• Only access the minimal data necessary to prove the vulnerability
• If you inadvertently access user data (personally identifiable information, confidential records, etc.), stop further access immediately
• Delete any sensitive data that you inadvertently obtained as soon as it is no longer relevant to demonstrating the issue, and confirm said deletion in writing

3. Use your own accounts / test accounts

• Use accounts you own or that have been explicitly provided
• Do not attempt credential stuffing, password spraying, or in any other way compromise a real user account

4. No escalation beyond necessity

• Don't pivot to deeper systems unless explicitly allowed or necessary to demonstrate the issue
• Avoid chain-of-vulnerability tests that may affect systems beyond scope without prior consent

5. Safe timing & disclosure

• Submit your report promptly once you identify a viable vulnerability
• Do not publish or share details publicly before we have addressed the issue (or you obtain explicit permission)
• If a deadline for public disclosure is proposed, it should be reasonable (we understand 90 days as an industry benchmark) and mutually agreed

6. Transparency & cooperation

• Provide clear reproduction steps, proof-of-concept code or examples where applicable
• Be responsive to clarifying questions during triage
• We would appreciate your assistance in retesting once we believe a fix is in place

A minimal viable report should include:

• Summary / Title
• Affected component(s) or URL(s)
• Step-by-step reproduction or proof-of-concept (with sanitized data)
• Impact / severity assessment (your view)
• Any relevant logs, HTTP requests/responses, screenshots
• Your preferred disclosure name (or "anonymous")
• Any other environment details (browser, OS, version, etc.)

Response & Timeline

• We will acknowledge receipt within 5 business days
• During triage we may follow up with clarifying questions
• We aim to fix critical/high issues as soon as reasonably feasible
• We will keep you informed of status / progress periodically

Disclosure & Public Release

• You may not publicly disclose the vulnerability until we have fixed it (or agreed with you to publish)
• After fix, we may publish a security advisory summarizing the issue, affected versions, and mitigation steps
• We commit to credit you in any public disclosure, and will honor requests for anonymity or pseudonymity