Vulnerability Disclosure Program

Cross-Site Scripting (XSS)


• Your XSS must display 'OPENBUGBOUNTY' string in a JS popup, for example:
  • <script>alert('OPENBUGBOUNTY')</script>
  • <img src=x onerror=prompt(/OPENBUGBOUNTY/)>
  • <script src=https://openbugbounty.org/1.js>
• Your XSS must affect the domain for which you submit the vulnerability - XSS in iframes or after redirects are not accepted.
• Iframe injections must contain an iframe with openbugbounty.org inside.
• Same XSS in different scripts (e.g. one global parameter affecting all pages) will NOT be published as separate XSSs, and will be deleted.
• Multiple re-submissions of the same vulnerability will result in removal of all these submissions.
• Please allow up to 24 hours for XSS approval and publication.
• Due to high amount of work required, mass posting vulnerabilities will NOT be re-checked if not accepted after submission.

Open Redirect


• Due to quite low security impact of Open Redirect vulnerabilities, they won't be included into any stats (e.g. they won't impact Top Security Researcher rating, etc).
• Your Open Redirect must redirect to openbugbounty.org website.
• Same Open Redirects in different scripts (e.g. one global parameter affecting all pages) will NOT be published as separate entries, and will be deleted.

Cross Site Request Forgery (CSRF)


• Your CSRF must not cause any harm or destructive actions beyond your personal account and your data on the affected website.
• Carefully follow the CSRF submission process.
• CSRF affecting similar functionality (e.g. impacting all fields in profile update OR the same impact but on different pages) must be submitted as one CSRF. Otherwise, they will all be deleted.

Improper Access Control (IAC)


• SQL injections, RFI/LFI or RCE are not allowed.
• Information Disclosure (CWE-200) is not allowed (e.g. phpinfo(), WordPress XMLRPC, wp-json, server-status, etc.)
• Submit a URL on which a non-authenticated, or authenticated but unprivileged user, can access sensitive data or administrative functionality (e.g. edit another user account or see list of orders done by other user).
• Make sure that this is not a built-in functionality or feature and that it represents a tangible risk (e.g. login interfaces to admin panels are not accepted).
• To protect privacy of the end-users, wherever possible, submit URLs that disclose information that belongs to user accounts preliminary registered by you for testing purpose. Submissions exposing critical personal data of third-parties, or large volume of personal data, will be declined for security reasons.

Please carefully follow submission guidelines:

• Your XSS must display 'OPENBUGBOUNTY' string in a JS popup, for example:
  • <script>alert('OPENBUGBOUNTY')</script>
  • <img src=x onerror=prompt(/OPENBUGBOUNTY/)>
  • <script src=https://openbugbounty.org/1.js>
• Your XSS must affect the domain for which you submit the vulnerability - XSS in iframes or after redirects are not accepted.
• Iframe injections must contain an iframe with openbugbounty.org inside.
• Same XSS in different scripts (e.g. one global parameter affecting all pages) will NOT be published as separate XSSs, and will be deleted.
• Multiple re-submissions of the same vulnerability will result in removal of all these submissions.
• Please allow up to 24 hours for XSS approval and publication.
• Due to high amount of work required, mass posting vulnerabilities will NOT be re-checked if not accepted after submission.

Please carefully follow submission guidelines:

• Due to quite low security impact of Open Redirect vulnerabilities, they won't be included into any stats (e.g. they won't impact Top Security Researcher rating, etc).
• Your Open Redirect must redirect to openbugbounty.org website.
• Same Open Redirects in different scripts (e.g. one global parameter affecting all pages) will NOT be published as separate entries, and will be deleted.
• Multiple re-submissions of the same vulnerability will result in removal of all these submissions.
• Please allow up to 24 hours for Open Redirect approval and publication.

Please carefully follow submission guidelines:

• Your CSRF must not cause any harm or destructive actions beyond your personal account and your data on the affected website.
• Carefully follow the CSRF submission process.
• CSRF affecting similar functionality (e.g. impacting all fields in profile update OR the same impact but on different pages) must be submitted as one CSRF. Otherwise, they will all be deleted.
• Multiple re-submissions of the same vulnerability will result in removal of all these submissions.
• Please allow up to 24 hours for CSRF approval and publication.

Please carefully follow submission guidelines:

• SQL injections, RFI/LFI or RCE are not allowed.
• Information Disclosure (CWE-200) is not allowed (e.g. phpinfo(), WordPress XMLRPC, wp-json, server-status, etc.)
• Submit a URL on which a non-authenticated, or authenticated but unprivileged user, can access sensitive data or administrative functionality (e.g. edit another user account or see list of orders done by other user).
• Make sure that this is not a built-in functionality or feature and that it represents a tangible risk (e.g. login interfaces to admin panels are not accepted).
• To protect privacy of the end-users, wherever possible, submit URLs that disclose information that belongs to user accounts preliminary registered by you for testing purpose. Submissions exposing critical personal data of third-parties, or large volume of personal data, will be declined for security reasons.