OWASP supports many volunteers efforts to produce security libraries which at the same time are used by many companies and developers, in order to secure their applications. This bounty program for Java HTML Sanitizer project run by OWASP is to determine the protection level claimed by the library and verify that indeed the protected application is not vulnerable to XSS attacks when using the library.
OWASP may provide rewards to eligible reporters of qualifying vulnerabilities. Our minimum reward is reputational points. The following table outlines the usual minimum rewards for specific classes of vulnerabilities for in-scope properties (see section on Scope).
Please be aware that the quality of your report is critical to your submission. To ensure that we are able to understand what you are reporting and the potential impact, please make sure your report contains the following items:
- What type of issue are you reporting? Does it align to the scoped issue?
- How does a user reproduce your issue? (If this contains more than a few steps, please create a video so we can attempt to perform the same steps).
- What is the impact of your issue?
- What are some scenarios where an attacker would be able to leverage this vulnerability?
- What would be your suggested fix?
Eligibility and Responsible Disclosure
We are happy to thank everyone who submits valid reports which help us improve the security of OWASP! However, only those that meet the following eligibility requirements may receive a monetary reward:
*You must be the first reporter of a vulnerability.
*The vulnerability must be a qualifying vulnerability (see below) associated with a site or application in scope (see above).
*We can’t be legally prohibited from rewarding you (for example, you can’t be a resident of or located within Cuba, Sudan, North Korea, Iran or Syria, a national of other certain countries, or on a denied parties or sanctions list).
*You may not publicly disclose the vulnerability prior to our resolution.
About the OWASP HTML Sanitizer Project
The OWASP HTML Sanitizer is a fast and easy to configure HTML Sanitizer written in Java which lets you include HTML authored by third-parties in your web application while protecting against XSS. The existing dependencies are on guava and JSR 305. The other jars are only needed by the test suite. The JSR 305 dependency is a compile-only dependency, only needed for annotations. This code was written with security best practices in mind, has an extensive test suite, and has undergone adversarial security review. A great place to get started using the OWASP Java HTML Sanitizer is here: https://github.com/OWASP/java-html-sanitizer/blob/master/docs/getting_started.md.
Access & Reporting
Please, make sure to follow the instructions to obtain a copy of the web application secured by OWASP Java HTML Sanitizer project here: https://github.com/OWASP/OWASPBugBounty/tree/master/JavaHTMLSanitizer. When submitting a bug be sure to specify the version of the application you are using, the client the vulnerability was found on, and other unique information that might be helpful for us to reproduce the vulnerability.
The OWASP Java HTML Sanitizer protects ONLY against XSS attacks, therefore the main purpose of the bounty is to attack the application only against these type of vulnerabilities.
To access the application please go to
All the instructions on running the web app in your environment are provided in here.
No credentials are necessary to login to the application. It runs a simple HTML form with different fields protected by the OWASP Sanitizer project.
The following policies have been configured in this application and therefore you should focus on attacking the application with XSS attacks that
- Attempt to inject HTML code, whether in plain text or encoded
- Any type of attack with exception of XSS
The following finding types are specifically excluded from the bounty:
Everything that is not an XSS/HTML injection such as
- Descriptive error messages (e.g. Stack Traces, application or server errors).
- HTTP 404 codes/pages or other HTTP non-200 codes/pages.
- Fingerprinting / banner disclosure on common/public services.
- Disclosure of known public files or directories, (e.g. robots.txt).
- Clickjacking and issues only exploitable through clickjacking.
- CSRF on forms that are available to anonymous users (e.g. the contact form).
- Logout Cross-Site Request Forgery (logout CSRF).
- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.
- Lack of Secure/HTTPOnly flags on non-sensitive Cookies.
- Lack of Security Speedbump when leaving the site.
- Weak Captcha / Captcha Bypass
- Forgot Password page brute force and account lockout not enforced.
- OPTIONS HTTP method enabled
- Username / email enumeration
- via Login Page error message
- via Forgot Password error message
- Missing HTTP security headers, specifically (https://www.owasp.org/index.php/List_of_useful_HTTP_headers), e.g.
- Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP
- SSL Issues, e.g.
- SSL Attacks such as BEAST, BREACH, Renegotiation attack
- SSL Forward secrecy not enabled
- SSL weak / insecure cipher suites