WePay asks that tests are performed against
stage.wepayapi.com. Our public staging server runs the
same code as production. Create as many test accounts there as you feel
necessary; actual customer data is strongly discouraged for exploits — a
reproduce case will suffice. One report to cover both domains is sufficient;
please perform testing against
stage.wepay.com to prevent service
interruption to our customers.
Vulnerabilities that may be specific to server configs (SSL settings,SSH
settings, etc) may also be tested on
wepayapi.com, as the environments may be configured
differently than their corresponding staging environments viz.; stage-
go.wepay.com, stage.wepay.com, stage-home.wepay.com, and stage.wepayapi.com
Functioning exploits are worth more money than reports that are copy- pasted from other security-related websites. A screenshot is much less useful than a video, and a functioning exploit will always have real code. Showing that there 's a potential issue is less valuable than exploiting a real issue.
If we have already received a report of a similar issue, which we believe would be resolved by the same fix that would resolve your issue, then we will mark your issue as a duplicate because the root-cause is the same.
If you make an effort to file a legitimate issue, and it is not necessarily a valid issue, we will generally close it as Informational (+0) — UNLESS it is clear that you made no effort to read these Guidelines, in which case we may choose to close as Not Applicable (-5) if the case is particularly egregious.
"Typical" web vulnerabilities are generally considered in-scope. This includes, but is not limited to:
Only software-based issues are eligible for reward, things such as physical attacks against our offices or data centers do not qualify, nor do social engineering attacks. Protocols or standards not developed by WePay are similarly excluded, as are "non-optimal" protocol settings (e.g., RC4, SSLv3) unless said settings are directly exploitable. If in doubt please report it :)
Out-of-scope domains include, but are not limited to:
Out of scope vulnerabilities include but are not limited to:
Our SDKs are also ineligible for reward, as is other software open-sourced by WePay (such as that found on https://github.com/wepay __).
Too many duplicates have been filed and we will reject all new reports out- of-hand as N/A
Only security vulnerabilities qualify for rewards, which start at $100 and will increase based on severity and scope. Reports of non-security issues are appreciated, but will not qualify for a reward and will be marked informative. WePay 's security team reserves final judgment regarding rewards.
While we certainly appreciate reports of a possible issue, the lack of a functioning exploit against the possible vulnerability means that most of these reports will not be eligible for a bounty. If we determine that your report is exceptional and is bounty-worthy, it will be paid-out from the bottom-end of the reward scale.
If you employ automated scanning tools, their requests must be rate limited to not exceed 3 requests per second without prior approval. Failure to do so may be considered a DoS attack and will result in disqualification from the program.
Automated vulnerability scanners commonly have low priority issues and/or false positives. Before submitting the results from a scanner, please take a moment to confirm that the reported issues are actually valid and exploitable. Please submit an issue only if you have exploited a real vulnerability.
You will qualify for bounty eligibility only if you are the first person to responsibly disclose an unknown issue. We intend to respond and resolve reported issues as quickly as possible, but please allow up to 14 days for a response and 90–120 days for a resolution (if we expect resolution to take longer, we will be upfront about this).
Issues not disclosed through HackerOne or by directly emailing firstname.lastname@example.org are ineligible and may result in removal from the program.
Zero members of our staff use Microsoft Windows, so videos which use Windows- specific tools are not helpful for reproducing issues. Videos should contain steps that can be reproduced without leveraging features that are specific to a single tool that is only available for Microsoft Windows.
We use Linux or OS X for everything. If your functioning exploit leverages a command-line tool, it should be a tool which works on OS X (Darwin), RedHat- based Linuxes (e.g., RHEL, CentOS) or Debian-based Linuxes (e.g., Debian, Ubuntu). If your functioning exploit leverages a GUI tool, it should be a tool which works on OS X.
Please use modern codecs and containers when submitting videos.
Contact us if you want more information.