Please make sure you do all of your testing on sandbox.reverb.com.

No technology is perfect, and Reverb.com believes that working with skilled security researchers across the globe is crucial in identifying weaknesses in any technology. If you believe you've found a security issue in our product or service, we encourage you to notify us. We welcome working with you to resolve the issue promptly.

Please do not interfere with our legitimate users while testing

Please use sandbox.reverb.com to conduct your testing. Do not use reverb.com for your testing or your program membership will be cancelled. Create your own data, do not interfere with existing data.

To test credit card flows like checkout, use these fake card numbers

https://docs.adyen.com/developers/test-cards/test-card-numbers __

Please do not use automated scans or DOS attacks

Any scanning or high-rate abuse of our site will lead to disqualification and suspension from the program. Please respect the user experience on our platform.

Disclosure Policy

• Let us know as soon as possible upon discovery of a potential security issue, and we'll make every effort to quickly resolve the issue.
• Provide us a reasonable amount of time to resolve the issue before any disclosure to the public or a third-party.
• Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder. Please don't spam or send excessive communications to existing user accounts, even in the sandbox environments.

Bounty Program

To show our appreciation of responsible security researchers, Reverb.com offers a monetary bounty for reports of qualifying security vulnerabilities. Reward amounts will vary based upon the severity of the reported vulnerability, and eligibility is at our sole discretion. These are the guidelines that we use when determining bounty rewards. All rewards are subject to Reverbs discretion. Not all bugs submitted will be rewarded. Duplicate issues will be merged.

Bounty begging will get you kicked out

Our bounties are final and are not up for negotiation. Attempting to negotiate for bounties will result in termination from our program.

Exclusions - What qualifies for a bounty?

Please see google's bughunter university page: https://sites.google.com/site/bughunteruniversity/nonvuln __- we follow the same rules.

Areas of highest interest

We are most interested in, and will pay higher bounties for the following items:

• Demonstrated XSS. In particular, stored and reflected XSS that leads to a victim loading an XSS planted by an attacker.
• Anything that allows bypass or gamification of the login system (aside from brute forcing or DoS).
• Things that exposes PRIVATE user data to other users in ways that are not intended. This means things like addresses, financial details etc - things like unpublished draft listings are not a security concern (see below).

Areas of lowest interest

• Best practice recommendations (DNSSEC, HSTS, SSL misconfiguration). You must demonstrate a security violation that results in modifying data or hacking someone's account.
• CORS - we get a lot of reports for CORS related stuff. We need a demonstrated vulnerability related to CORS if you want to report it. Querying our APIs via CORS is not a vulnerability, unless you can show exposure of sensitive information that would normally not be available.
• CSRF - The authenticity token for CSRF POSTS gets stored in the session cookie. If you are going to demonstrate a CSRF exploit, makes sure you test with the token removed from the cookie's contents as well.
• HTML input - some of our forms allow the submission and rendering of HTML. If you want to submit a vulnerability that is more than just a best practice, please show an actual exploit (such as credential theft or XSS).
• CVEs for versions of software you may identify we are running unless you can show an actual vulnerability
• IDOR - things like "I can craft a URL that lets me see unpublished draft listings" that you perform in Burp but not in the app itself. While it's certainly an issue, we view these more as bugs, not a huge security concern for us.

Common Reports We Get that are Out of Scope

• Cookie replay or session expiration based reports - sessions to do not expire on logout by design. They do expire on password reset.
• Being able to craft <a> or <img> links that link offsite. This is not XSS.
• Rate limiting missing or not working - we are aware of our rate limiting policies. We have different detection systems in place in our production environments that are not in our sandbox environment - please don't file any tickets regarding any type of rate limiting, as they will almost always be not-applicable.
• "If I take my session cookie and put it in another browser, it acts like I'm logged in" - yes, we know, this is exactly how cookies are supposed to work. This is not a bug. If someone can steal your cookie, they can impersonate you. If you can find a way to steal the cookie, then report that instead.
• The status of SameSite or HTTPOnly attributes on various cookies. We're happy with our current settings.

Out of scope:

• Any and all reports regarding password policies, password complexity requirements, session timeout password change flows, password reset flows, email confirmations stemming from password changes, etc. We've evaluated our password requirements and we are satisfied with current policies.
• Best practices, such as "disabling autocomplete on forms"
• Image uploads - we use a 3rd party service for hosting images and other certain attachable items. We know you can upload things aside from images, this is by design. Unless you can find an actual exploit or hack of the reverb.com site, we're not concerned on this front.
• Old posts with links to social media profiles that may no longer exist. We're not worried about things like Terms and Conditions from a contest we ran in 2014 that has a link to a twitter page that we no longer own.

While researching, we'd like to ask you to refrain from:

• Denial of service
• Spamming
• Social engineering (including phishing) of Reverb.com employees or contractors
• Any physical attempts against Reverb.com property or data centers
• POCs that require social engineering (for example, content injection) unless the content injection is truly sneaky.

Thank you for helping keep Reverb.com and our users safe!