⚠️ By participating in this program, you agree to:

• Follow the Community Code of Conduct
• Honour the Intigriti Terms and Conditions
• Respect the scope of the program

🧑‍🏫 Discussing and disclosing vulnerabilities
We know that some researchers who find really interesting bugs would like to discuss them or share them with others, like:

• Presenting findings at security conferences
• Writing blog posts about discoveries
• Creating videos that present proof-of-concepts
• Discussing findings in social media platforms, like Reddit

We kindly ask that you don't discuss or disclose the details of bugs you have reported to us though without our consent. We need time to fix the bugs! 🧑‍🔧

Once the bug is fixed and confirmed to no longer be vulnerable, we're happy to collaborate on safely presenting discoveries to the wider security community 🤝.

Validation times

We will validate all submissions within the below timelines, once your submission has been verified by Intigriti.
Submissions validated outside of this may be awarded a €25 bonus.

This remains at the discretion of Monzo Bank to award.

Check our fix
We offer up to €50 bonus to verify a resolved issue for us (when requested).

This remains at the discretion of Monzo Bank to award.

ℹ️ Introduction

👋 Welcome to the Monzo public bug bounty program! We're glad to have you onboard! 🚀

Monzo takes the security of our products seriously, as keeping them as safe as possible keeps our customers just as safe 🔒. We consider security a high priority at Monzo, but there are only so many eyes we can get to look at our products with a security focus.
We see huge value in the contributions of the security community and the breath of creativity and diverse thinking that they can provide.

We do our best to catch and squash bugs before products release, but we believe getting more, independent eyes looking will help find any bugs that we missed. Together we can make Monzo’s products safer for everyone! 👍

😓 Worst-Case Scenarios

At Monzo, our worst-case scenarios revolve around our customers. Scenarios we would consider show stoppers include:

• Customer accounts being taken over
• Money being stolen from our customers
• Our customers personal information being disclosed to unauthorised entities
• Payment card details being stolen
• Attackers defrauding our systems

Really anything that could lead to or aid an attacker to attack our customers, commit fraud, or impact the services we provide within the in-scope assets.

💬 No-bounty bugs

There are some issues that we won't pay bounties for without a proven exploit. However, in their unproven state we'd still be interested to hear about them.

• Blind SSRF without sensitive data being returned (such as HTTP and DNS ping-backs)
• Self-XSS without a way to compromise other users (e.g. using HTTP request smuggling / tunnelling)
• HTTP request smuggling / tunnelling without any proven impact
• Host header injection without proven business impact

🗣️ Feedback
If you have any suggestions or feedback about our program, whether good or bad, we would love to hear your thoughts! You can send these to us using the anonymous form at the link below.

Program feedback link

We can't check feedback all the time though, so please don't use this for submission or support queries.

🥉 Third-parties

The third-party systems we use are out of scope for our program.

We don't have explicit permission for researchers to test them. Examples of third-parties we use are below, but this list is just a handful:

• Okta
• Discourse
• Mailgun
• Adjust
• Braze

🗝️ OAuth2

At Monzo, every API call needs to be authenticated in some way. We do this by using OAuth2 clients which are turned into bearer tokens. Some features are meant to be used by unauthenticated users (think people who don't have a Monzo account but want to pay a Monzo customer, or a customer who hasn't authenticated yet). To allow this, we make use of public OAuth2 clients with limited capabilities.

To help researchers prioritise their efforts, we've provided the below list of public OAuth2 clients that are out-of-scope. It may not have every public client, but should contain the main ones.

• oauth2client_00009dFUFY76z95Llb6GmX
• oauth2client_00009dFUM4BKfa5YIDRG4H
• oauth2client_00009dPfUCceDJVoX5djgf
• oauth2client_00009eSdYUPISh6oAUCeyP
• oauth2client_00009ETVigce5mXattBI8H
• oauth2client_00009f5dqwqJ3TWDzcpQsT
• oauth2client_00009f5ehvesBnSjqJi1lB
• oauth2client_00009fOPyTRaXFu7CrGzWz
• oauth2client_00009fUtrFdXdQ0IlO5eID
• oauth2client_00009io4Ks1KpjvH51tlaL
• oauth2client_00009io7fjJAijLGwxzY5x
• oauth2client_00009WbGxg4fIiPQD7raLp
• oauth2client_00009XXTN0biZ3vgvysb21
• oauth2client_0000ATbSRBo8E4Es6Ss3k6
• oauth2client_0000ATfyzfPucTcqsdvQ6z
• oauthclient_00008zhm3PSIjngfsfonmT
• oauthclient_000094oi2ytifdsiO84Xfl
• oauthclient_000097JsUCy1aF4Hud2iJN
• oauthclient_00009BNHPUMGlKOkL9kg5Z
• oauthclient_000094PvINDGzT3k6tz8jp
• oauth2client_0000AjcHJnoEt7UzxFbKT4
• oauth2client_0000AhsW1TrOpmk82bds9Z

🎫 Issues

Several issues are not in-scope of the Monzo public bug bounty program and will not result in an award. These issues are listed in their respective categories below.

📦 General

• Issues already known to Monzo by internal testing will be marked as duplicates
• Issues that are theoretical only with no realistic exploitation scenarios
• Issues that require unrealistic, unlikely, and complex end user interactions to be exploited
• Transport security (SSL/TLS) issues without proof-of-exploits (but within the bound of the two points above).
• Issues based upon social engineering or physical access to end user devices
• Intentionally performing DoS / DDoS attacks
• Bypassing rate-limiting or the non-existence of rate-limiting
• Brute-force attacks (such as password spraying)
• Attacks against third-party systems Monzo uses (such as Okta)
• Issues requiring an person-in-the-middle scenario to be exploited
• Issues that require an end user to already be compromised (e.g. the result of an account takeover)
• Disclosure of OAuth client IDs and secrets without proof of exploitation
• Public zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis
• Missing email best practices (invalid / incomplete / missing SPF / DKIM / DMARC records, etc.)
• Software version disclosure / banner identification issues / descriptive error messages or headers without sensitive information in them (e.g. stack traces, application, or server errors)
• Verbose messages / files / directory listings without leaking any sensitive information
• API key disclosure used for non-sensitive activities / actions
• Leaked information in archiver sites, search engines and other web scrapers without a proven flaw in Monzo's systems leading to the behaviour

🕸️ Web applications and APIs

• API key disclosure without proven business impact
• Username / email address enumeration
• Account pre-staging / OAuth squatting attacks
• Content spoofing and text injection issues without showing an attack vector / without being able to modify HTML / CSS
• Missing best practices for Content Security Policy (CSP)
• Missing HttpOnly, Secure, or SameSite attributes on cookies
• Reverse tabnapping
• Cross-site request forgery with no or low impact
• Presence of autocomplete attribute on input forms
• Files with metadata present
• CORS misconfigurations
• Missing security-related HTTP headers (X-XSS-Protection, X-Frame-Options, Strict-Transport-Security, etc.)
• Best practice violations (password complexity, expiration, re-use, etc.)
• Clickjacking without proven impact / unrealistic user interaction required
• CSV injection
• Sessions not being invalidated (logout, enabling 2FA / MFA, etc.)
• Email bombing
• Homograph / homoglyph attacks
• XML-RPC enabled
• Subdomain takeover without taking over the subdomain
• Arbitrary file upload without being able to load the uploaded file
• Cloud credentials / keys without proving exploitability (e.g. proving accounts can be used to authenticate)

📱 Mobile Applications

• No or ineffective jailbreak / root detection
• No or ineffective anti-reversing controls (e.g. obfuscation, runtime tampering, debugging, emulator detection)
• No or ineffective certificate validation and pinning
• Disclosure of paths in binary (such as file system paths of the system where the app was compiled)
• Disclosure of API keys for non-sensitive uses
• Exploits only possible upon a jailbroken or rooted end user device

📘 Monzo.me

To maintain focus on core banking security, functionality related to social interaction and peer-to-peer features is considered out of scope for this bug bounty program. This includes contact discovery and Monzo.me services.
Specifically, the following domains and endpoints are excluded:

• monzo.me/,
• .monzo.me/,
• /contact-discovery/,
• /inbound-p2p/,
• /p2p/

This program follows Intigriti's triage standards

🔑 How do I get credentials for the app?

No credentials will be provided in this public program. Please use your own credentials but note that no refunds will be issued for transactions during testing of the Monzo assets

🎫 I found an OAuth secret! Is it meant to be exposed?

We often get a lot of submissions for "exposed" OAuth 2.0 client secrets. At Monzo we need the majority of APIs to present an access token. To achieve this we use public OAuth 2.0 credentials which grant limited access to resources (scopes).

To understand this pattern, have a look at the excellent page by Auth0 at https://auth0.com/docs/get-started/applications/confidential-and-public-applications.

We've tried to include as many public client IDs as possible in the out-of-scope section (which you should always check first!), but there is a way to check whether a client is confidential or public yourself.

Below shows a request and response you can use. These use public credentials that the Monzo Me (https://monzo.me) app will return (from /oauth2/token).

GET /oauth2/clients/oauthclient_000094PvINDGzT3k6tz8jp HTTP/2
Host: internal-api.monzo.com
--snipped--
__auth_v2: true
Authorization: Bearer eyJhbGciO[REDACTED]SecMtg
--snipped--

HTTP/2 200 OK
--snipped--

{
    "id": "oauthclient_000094PvINDGzT3k6tz8jp",
    "name": "Monzo Developer Portal",
    "description": "https://developers.monzo.com",
    --snipped--
    "confidential": false,
    --snipped--
}

In the response is the property confidential. If it's false, the client is a public one and the secret is meant to be exposed. If it's true, and you have the secret, we'd like to know about it to see why that's the case!

Note the published property controls who the client can authenticate, it doesn't mean it's public/exposed.