GoCardless is on a mission to take the pain out of getting paid for businesses with recurring revenue. We’ve created a global bank debit network, to rival credit and debit cards. On top of it, we’ve built a platform designed and optimised for taking invoice, subscription, membership and instalment payments.

Our recurring payments platform integrates with the applications businesses use every day, giving businesses more visibility over payments and saving them huge amounts of time on tasks like payment reconciliation.

GoCardless looks forward to working with the security community to find security vulnerabilities in order to keep our businesses and customers safe.

We really appreciate your help in uncovering any security issues and look forward to your findings.

Disclosure Policy

Any public-facing website owned, operated, or controlled by GoCardless including web applications hosted on those sites.

Please do not discuss any vulnerabilities (even resolved ones) outside of the program without express consent from GoCardless.

Follow HackerOne's disclosure guidelines.

Response Targets

GoCardless will keep you informed about our progress throughout the process.

Rules of Engagement

Your participation in our program is voluntary and subject to the following:

• You must include a working Proof of Concept.
• You must not threaten or try to extort GoCardless or our customers.
• You must not access, modify, copy, download, delete, compromise, or otherwise misuse others’ data.
• You must not access non-public information without authorization.
• You must not degrade, interrupt, or deny services to our users.
• You must not incur a loss of funds that are not your own.
• You must use your own accounts and not interact with other users’ accounts or data.
• You must use your HackerOne email alias for accounts when conducting research on our platform
• When duplicate reports occur the first report that can be fully reproduced may be eligible for a reward at GoCardless' discretion
• Chained/Multiple vulnerabilities caused by a single underlying issue are eligible for a single reward at GoCardless' discretion

Setting up accounts for vulnerability research

You must use a HackerOne email alias account for accounts configured in our environments.

Please add bug bounty to the company or name field to make the account easily identifiable a security researcher

You can create your own accounts using a HackerOne email alias, by signing up with [email protected] (e.g. [email protected])

See more here: https://docs.hackerone.com/hackers/hacker-email-alias.html

To get started on the GoCardless platform there is extensive documentation about the types of accounts that can be setup we recommend that you review the documentation in

• Getting started with GoCardless
• GoCardless guide for developers
• Partner integration getting started guide
• Schema details

When conducting research and testing please conduct testing in our sandbox environment (https://manage-sandbox.gocardless.com).

There are various roles in the GoCardless platform for merchants, all of these roles provide a level of administrative access. You can find out more about the different roles in https://support.gocardless.com/hc/en-gb/articles/210387925-Adding-additional-account-users

Scope

The scope has been deliberately loosely defined to encourage a wide range of impactful findings subject to the restrictions set out in the Out of scope vulnerabilities section below; however, we ask that you do not conduct testing on our production environments for our platform:

• https://api.gocardless.com (please use https://api-sandbox.gocardless.com instead)
• https://manage.gocardless.com (please use https://manage-sandbox.gocardless.com instead)
• https://xero.gocardless.com (please use https://xero-sandbox.gocardless.com instead)

Our publicly supported GitHub repositories (https://github.com/gocardless?q=&type=public&language=&sort=) are in scope where we have open-source projects that are explicitly supported by GoCardless and have a security policy file defined. Forks, mirrors and archived repositories are out of scope.

See the scoped domains for further details on the scopes and severity of findings that we accept reports against, these include internal services that we utilise.

Services out of scope

Third-party SaaS services even if they are accessible under an in scope URL. This would typically include services such as Zendesk or externally hosted forms. Please submit via their own Vulnerability Disclosure program respectively.

Github repositories in the GoCardless organisation that are forks, mirrors or archived repositories.

Out of scope vulnerabilities

When reporting vulnerabilities to GoCardless please consider (1) attack scenario/exploitability, and (2) the security impact of the bug. The following issues are considered out of scope unless you can demonstrate an exploitablity that does not require social engineering or user manipulation.

• Clickjacking
• Unauthenticated logout/login CSRF
• Attacks requiring MITM or physical access to a user's device.
• Previously known vulnerable libraries without a working Proof of Concept (PoC)
• Public zero-day vulnerabilities that have an official patch released for less than 30 days will be reviewed on a case by case basis
• Comma Separated Values (CSV) injection
• Missing best practices in SSL/TLS configuration
• Missing best practices in Content Security Policy
• Missing cookie flags
• Email best practices (Invalid, incomplete or missing SPF/DKIM/DMARC records, etc.)
• Vulnerabilities only affect users of outdated or unpatched browsers and operating systems
• Information disclosure such as software versions, banners or health check endpoints
• Rate limiting issues that lead to spam.
• Content spoofing and text injection issues without a PoC not requiring modification of the page content directly.
• CSRF on non-sensitive pages
• CORS headers misconfiguration without demonstrating the impact
• User enumeration
• Read-write & read-only user permissions: these roles shared common permissions, so privilege escalations reports that do not prove unexpected behaviour from either are not in scope.
• Public user registration to Jira service desk instance where there is not a demonstrable security impact
• Hypothetical subdomain takeovers without supporting evidence
• Issues that are premised on an unlikely user interaction
• Open redirect - unless an additional security impact can be demonstrated
• Rate limiting or brute-forcing of endpoints not related to authentication

Safe Harbor

Any activities conducted in a manner consistent with this policy will be considered authorised 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.