Product Cybersecurity Vulnerability Reporting - Scope & Rules of Engagement

Rules of Engagement
  • No Denial-of-Service testing
  • No Physical or Social Engineering
  • No testing of Third-party Services
  • No uploading of any vulnerability or client-related content to third-party utilities (e.g., GitHub, Drobox, YouTube)
  • All attack payload data must use professional language.
  • If able to gain access to a system, accounts, users, or user data, stop at point of recognition and report. Do not dive deeper to determine how much more is accessible.
  • When documenting a vulnerability, if a vulnerability is public, please make sure it is discreet and doesn't identify the client.
Low Impact Vulnerabilities – Out-of-Scope

The following vulnerabilities are considered as low impact are considered out-of-scope:

  • Google Maps API Keys
  • Account/e-mail enumeration using brute-force attacks.
  • User account/email enumeration not requiring brute-force will be considered in-scope.
  • Any low impact issues related to session management (i.e., concurrent sessions, session expiration, password reset/change log out, etc.)
  • Bypassing restrictions in uploading a file without proving the file was received.
  • Clickjacking/UI redressing
  • Client-side application/browser auto-complete or saved password/credentials
  • Descriptive or verbose error pages without proof of exploitability or obtaining of sensitive information.
  • Directory structure enumeration (unless the fact reveals exceptionally useful information)
  • Incomplete or missing SPF/DMARC/DKIM records
  • Issues related to password/credential strength, length, lockouts, or lack of brute-force/rate-limiting protections.
  • Account compromises (especially admin) as a result of these issues will likely be considered in-scope.
  • Lack of SSL or Mixed content
  • Leaking Session Cookies, User Credentials, or other sensitive data will be reviewed on a case-by-case basis.
  • If leaking of sensitive data requires MiTM positioning to exploit, it will be considered out-of-scope.
  • Login/Logout/Unauthenticated/Low-impact CSRF
  • CSRF Vulnerabilities may be acceptable if they are of higher impact. Examples of low impact CSRF include: Add/Delete from Cart, Add/remove wishlist /favorites, Non-severe preference options, etc.
  • Low impact Information disclosures (including version disclosure)
  • Missing Cookie flags
  • Missing/Enabled HTTP Headers/Methods which do not lead directly to a security vulnerability.
  • Reflected file download attacks (RFD)
  • Self-exploitation (i.e., password reset links or cookie reuse)
  • SSL/TLS best practices that do not contain a fully functional proof-of-concept.
  • URL/Open Redirection
  • Use of a known-vulnerable library which leads to a low-impact vulnerability (i.e., jQuery outdated version leads to low impact XSS)
  • Valid bugs or best practice issues that are not directly related to the security posture of the client.
  • Vulnerabilities affecting users of outdated browsers, plugins, or platforms.
  • Vulnerabilities that allow for the injection of arbitrary text without allowing for hyperlinks, HTML, or JavaScript code to be injected.
  • Vulnerabilities that require the user/victim to perform extremely unlikely actions (i.e., Self-XSS)
  • Self-XSS for a Persistent/Stored XSS will be considered. Please review the Self-XSS article for more information.
  • Any type of XSS that requires a victim to press an unlikely key combination is NOT in scope (i.e., alt+shift+x for payload execution)

Additional specific vulnerability types considered out of scope due to low impact:

  • IIS Tilde File and Directory Disclosure
  • SSH Username Enumeration
  • WordPress Username Enumeration
  • SSL Weak Ciphers/ POODLE / Heartbleed
  • CSV Injection
  • PHP Info
  • Server-Status if it does not reveal sensitive information.
  • Snoop Info Disclosures