About

About Paddle

Paddle.com Market Limited (and our subsidiaries) ("Paddle", or the "Company") offers SaaS companies a completely different approach to their payments infrastructure. Instead of assembling and maintaining a complex stack of payments-related apps and services, we're a merchant of record for our customers, taking away 100% of the pain of payments fragmentation. It's faster, safer, simpler, and above all, way better.

At Paddle we recognise the important role that security researchers play in helping to keep the Company and our customers secure. The goal of this Bug Bounty Program is to continuously improve our security posture at Paddle.

By participating in this Program, you acknowledge that you have read and agreed to these Program rules.

About the scope of this Program

We ask you to respect the scope of our program and to not hunt outside of it. Should you need to report anything outside of the scope of this program you may do so through our VDP program here https://vdp.paddle.com.

Sandbox environment

For any in-scope endpoint marked with "(and sandbox)", an equivalent sandbox environment is available by prefixing sandbox- to the domain (for example, vendors.paddle.com has a sandbox version at sandbox-vendors.paddle.com).

Our production and sandbox environments are equivalent and run the same code, so a vulnerability on one should be present on the other. Thus the same valid vulnerability uncovered both on sandbox and production environments will only warrant a single reward and should be reported through the same report.

The sandbox environment does not process real payments, nor do the test transactions that flow through it have any tax implications. Tests which involve financial transactions must not be carried out on the production environment. There are test cards which can be used on the sandbox environment to simulate a real purchase. To ensure you are able to test the full Paddle platform, please focus on testing on our sandbox environment.

https://www.paddle.com/

This is our main website, providing company and product information to our customers and stakeholders.

https://vendors.paddle.com/ (and sandbox)

This is our vendor dashboard application, providing self-service access to configuration for Paddle's products.

Please note that specific testing precautions apply to the production environment, see above.

https://api.paddle.com/ (and sandbox)

This is the entrypoint to Paddle’s API platform. Documentation is listed below under the API Reference link.

Checkout/payment functionality

As documented above (see "Sandbox environment"), tests on the following two endpoints are only permitted on the sandbox environment.

• https://sandbox-checkout-service.paddle.com/
• https://sandbox-buy.paddle.com/

https://developer.paddle.com/

This is our developer documentation website.

The following sections of our documentation may be useful as you test the platform:

• Get Started - get up and running with a Paddle checkout
• Test Cards - allow payments to be simulated in the sandbox environment
• API Reference
• Webhook Reference
• Next.js Starter Kit

About specific non qualifying issues

Account issues due to unverified email addresses (i.e. the ability to set MFA)

We're aware of various behaviours around MFA and email addresses verifications that you may consider reporting through our program. Those are known to us and by design as to improve user experience and foster a smoother onboarding process, they won't warrant a reward.

Access control issues linked to 'hidden' pages or features

You may stumble upon features or pages that are not accessible from the UI but may still be interacted with through direct requests. This is often by design as they're legitimate features/pages that are hidden to foster a better user experience and clearer UI. Reports about it won't warrant any reward. An example of this is with the “Invoicing” role, where some pages such as “Customers” cannot be viewed, but the role still allows access to manage customers (and indeed this can be done directly on the “Invoices” page.

Main out of scope assets

• https://checkout-service.paddle.com/ - testing is only permitted on the sandbox environment, see above
• https://buy.paddle.com - testing is only permitted on the sandbox environment, see above
• All domains not listed in-scope

Program Rules

Participants are permitted to perform tests and investigations on Paddle's systems, as long as they act in good faith and respect the scope and rules described below. This Program does not give you permission to act in any manner that is inconsistent with the law, or which might cause the Company or partner companies to be in breach of any legal obligations.

Reporting & Disclosure Policy

Paddle 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 products or services, we encourage you to notify us. We welcome working with you to resolve the issue promptly.

Program Rules

Testing Policy and Responsible Disclosure

Please adhere to the following rules while performing research on this program:

• Denial of service (DoS) attacks on our applications, servers, networks or infrastructure are strictly forbidden.
• Avoid tests that could cause degradation or interruption of our services.
• Do not use automated scanners or tools that generate large amounts of network traffic.
• Do not leak, manipulate, or destroy any user data or files in any of our applications/servers.
• Do not copy any files from our applications/servers and disclose them.
• No vulnerability disclosure, full, partial or otherwise, is allowed.

Reward Eligibility and Amount

We are happy to thank everyone who submits valid reports which help us improve our security, 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 per the entirety of the program rules and scopes.
• The report must contain the following elements:
  • Clear textual description of the vulnerability, how it can be exploited, the security impact it has on the application, its users and our organisation, and remediation advice on fixing the vulnerability
  • Proof of exploitation: screenshots demonstrating the exploit was performed, and showing the final impact.
  • Provide complete steps with the necessary information to reproduce the exploit, including (if necessary) code snippets, payloads, commands etc.
• You must not break any of the testing policy rules listed here.
• You must not be a former or current employee of our organisation or one of its contractors.
• If you find the same vulnerability several times, please create only one report and use comments to add further context. You'll be rewarded according to your findings.

Reward amounts are based on:

• Reward grid of the report's scope
• CVSS scoring and actual business impact of the vulnerability upon performing risk analysis

Reports of leaks and exposed credentials

In the context of this program, we do not intend to encourage, accept or reward reports of leaks that are not applicable to our program’s scope and identified outside of our program’s scope, such as:

• Exposed credentials in/from an out-of-scope asset/source
• Sensitive information exposed in/from an out-of-scope asset/source

Also, in order not to encourage dark and grey economies, in particular the purchase, resale and trade of identifiers or stolen information, as well as all types of dangerous behaviour (e.g. social engineering, ...), we will not accept or reward any report based on information whose source is not the result of failure on the part of our organization or one of our employees/service providers.

This excludes, but is not limited to:

• Stolen credentials gathered from unidentified sources
• Exposed credentials that are not applicable on the program’s scope
• Exposed GitHub/GitLab (or similar) instance or repository with no direct relation with our program’s scope
• Exposed secrets (e.g. API tokens/keys or other technical credentials) that are not directly related to the program’s scope
• Exposed PII on an out-of-scope asset

To summarize our policy, you may refer to this table :

Important precautions and limitations

As a complement to the Program’s rules and testing policy :

• DO NOT alter compromised accounts by creating, deleting or modifying any data
• DO NOT use compromised accounts to search for post-auth vulnerabilities (they won’t be eligible anyway)
• DO NOT include Personally Identifiable Information (PII) in your report and please REDACT/OBFUSCATE the PII that is part of your PoC (screenshot, server response, JSON file, etc.) as much as possible.
• In case of exposed credentials or secrets, limit yourself to verifying the credentials validity
• In case of sensitive information leak, DO NOT extract/copy every document or data that is exposed and limit yourself to describe and list what is exposed.

Testing precautions

• The user-agent suffix is mandatory.
• The sandbox and production environments share the same code and run on equivalent infrastructure. You may check if you’re able to reproduce any vulnerability on the other environment from the one you discover it on (subject to the Program rules), but only one reward will be considered.

Third-party tool usage

The use of third-party sites or tools for vulnerability testing is prohibited (for instance - XSS Hunter or its variants). We ask you to only use assets that you own/control for the purpose of your tests (e.g. self hosted versions of tools like XSS Hunter are allowed). Please make sure that all traffic goes through domains only you have control over, failing to comply with these guidelines may result in forfeiture of any reward.