• Provide clear, complete, and reproducible steps to demonstrate the issue.

• Submit one vulnerability per report, unless chaining is required to demonstrate impact.

• Duplicate reports are triaged based on the first valid submission received.

• Multiple vulnerabilities caused by a single root issue will be treated as one report.

• Social engineering (e.g. phishing, vishing, smishing) is prohibited.

• Act in good faith—avoid privacy violations, data destruction, or service disruption. Only test against accounts you own or have explicit permission to use.

When reporting vulnerabilities, consider both exploitability and security impact. The following issues are out of scope:

• Clickjacking on pages without sensitive actions.

• Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms without sensitive operations.

• Attacks requiring Man-in-the-Middle (MITM) positioning or physical access to a user’s device.

• Reports of known vulnerable libraries without a working Proof of Concept.

• Comma-Separated Values (CSV) injection without demonstrated exploitability.

• Missing SSL/TLS best-practice configurations.

• Any activity that could disrupt service availability (including DoS scenarios).

• Content spoofing or text injection without a viable attack vector or ability to modify HTML/CSS.

• Rate-limiting or brute-force concerns on non-authentication endpoints.

• Missing Content Security Policy (CSP) best practices.

• Missing HttpOnly or Secure flags on cookies.

• Email configuration best-practice issues (e.g., incomplete or missing SPF, DKIM, or DMARC records)

• Issues affecting only outdated or unpatched browsers (more than two stable versions behind).

• Software version disclosure, banner identification, or descriptive error messages or headers (e.g. stack traces, application or server errors).

• Tabnabbing.

• Open redirects without additional demonstrated security impact.

• Issues requiring unlikely or highly impractical user interaction.