MoonPay

#MoonPay Bug Bounty Program

At MoonPay, we are committed to maintaining the security and privacy of our products and customers. We believe that working with the security research community through our bug bounty program is a crucial part of our overall security strategy. We are grateful for the contributions of the security community, and we look forward to working together to keep MoonPay secure.

If you have any questions about the scope of our bug bounty program or if you are unable to properly access or test the assets in scope, please contact us at [email protected].

#Response Targets

MoonPay will make a best effort to meet the following SLAs for hackers participating in our program:

We will do our best to keep you informed about our progress throughout the process.

#Disclosure Policy

• Please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the MoonPay Security team.
• Follow HackerOne's disclosure guidelines.

#Program Rules

Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.

• Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.
• When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).
• Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.
• Social engineering (e.g. phishing, vishing, smishing) is prohibited.
• 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.

#Out of scope vulnerabilities

When reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:

• Reporting on general security best practices, such as password strength guidelines, password policies.
• Identifying missing security features or controls that are not specific to the application or service.
• Clickjacking
• Email or Nonces sent to third party domains
• Unconfirmed reports from automated vulnerability scanners
• Security weaknesses with no evidence of the ability to target a remote victim. For example: HTTP Host header attack, missing rate limits, bruteforcing without demonstrating impact, etc.
• Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions
• Attacks requiring a MITM or physical access to a user's device
• Previously known vulnerable libraries without a working Proof of Concept
• Comma Separated Values (CSV) injection without demonstrating a vulnerability
• Missing best practices in SSL/TLS configuration
• Arbitrary file upload
• Email flooding
• User enumeration
• Any activity that could contribute to the disruption of our service (DoS).
• Content spoofing and text injection issues
• Theoretical subdomain takeovers with no supporting evidences
• Missing Content Security Policy
• Missing HttpOnly or Secure flags on cookies
• Missing email security best practices (Invalid, incomplete or missing SPF/DKIM/DMARC records, etc.)
• Vulnerabilities only affecting users of outdated or unpatched browsers
• Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g., stack traces, application or server errors)
• Tabnabbing
• Self XSS
• Broken links
• Open redirect - unless an additional security impact can be demonstrated
• Rate limit bypass through IP rotation techniques
• Session invalidation issues (logout not expiring sessions)
• Issues that require unlikely user interaction by the victim
• Vulnerabilities on subdomains that point to third party services.
• Disclosure of API keys with the prefix pk_*. These are publishable keys and are not sensitive.
• Invalid or stale employee credential dumps - we already monitor haveibeenpwned.com and other sources for dumps of this nature.

Out of scope bugs for iOS and Android apps:

• Root / Jailbreak detection bypass
• Lack of Root / Jailbreak detection
• Bypass of certificate pinning
• Lack of binary protection (anti-debugging, PIE, ARC, or Stack Canaries) controls
• Lack of obfuscation
• Snapshot/Pasteboard leakage
• Crashes in general
• Runtime hacking exploits (exploits only possible in a rooted/jailbroken environment)
• Hardcoded keys or values, if they do not provide functionality beyond the normal application functionality (eg ability to escalate privileges beyond normal application access)
• Any kind of sensitive data stored in app private directory

#Rewards

• Rewards are based on severity per CVSS (the Common Vulnerability Scoring Standard).
• Reports submitted using methods that violate policy rules will not be eligible for a reward. To be eligible for a reward, the report must be for bounty eligible assets as defined in the scope section of our policy.
• Multiple reports describing the same vulnerability against multiple assets or endpoints where the root cause is the same will be treated as one report. Do not submit duplicate reports for the same issue across multiple sites as the duplicates will be closed, and the issue will be treated as one report.
• While we aim for consistency, previous reports and prior bounty amounts will not set a precedent for future report eligibility or severity.
• Understand that there could be submissions for which we accept the risk, have other compensating controls, or will not address in the manner expected. When this happens, we will act as transparently as we can to provide you with the necessary context as to how the decision was made.

#Program Eligibility

• You agree and adhere to the Program Rules and Legal terms as stated in this policy.
• You are the first researcher to submit a sufficiently reproducible report for a vulnerability in order to be eligible for the report to be accepted and Triaged. You are available to supply additional information, as needed by our team, to reproduce and triage the issue.
• Publicly-known zero-day vulnerabilities will not be considered for eligibility until more than 30 days have passed since patch availability.
• Eligibility of reports about assets that are not explicitly listed as in-scope will be reviewed on a case-by-case basis.
• MoonPay employees, contractors and other personnel are not eligible for participation in this program.

#Safe Harbor

Any activities conducted in a manner consistent with this policy will be considered authorized conduct and we will not initiate legal action against you. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will take steps to make it known that your actions were conducted in compliance with this policy. Thank you for helping keep MoonPay and our users safe!

#Legal

MoonPay reserves the right to modify the terms and conditions of this program, and your participation in the Program constitutes acceptance of all terms. Please check this site regularly as we routinely update our program terms and eligibility, which are effective upon posting. You can subscribe to receive email notifications when this policy is updated.