Details

Important announcement

Badoo bug bounty program will join Bumble from 22nd February 2021. For more details, please visit https://hackerone.com/bumble. Please, submit all your reports to Bumble bug bounty from now on.

Badoo vulnerability disclosure program

We pay for all newfound vulnerabilities.

Vulnerabilities will be ranked from category 5 (£3000) to category 1 (£300), depending on their severity. The Badoo jury determines the severity of the vulnerability.

Where to look for vulnerabilities:

badoo.com,
eu1.badoo.com,
us1.badoo.com,
corp.badoo.com,
m.badoo.com,
meu1.badoo.com,
mus1.badoo.com,
hotornot.com
bma.badoo.com
badoocdn.com
translate.badoo.com
ccardseu1.badoo.com
ccardsus1.badoo.com
Badoo Mobile Applications (App Store, Google Play).

Award categories

Category 5 - £ 3000
Category 4 - £ 2000
Category 3 - £ 1000
Category 2 - £ 600
Category 1 - £ 300

We don’t want to tie our categories to traditional systems of vulnerability assessment. The more damage a discovered vulnerability can cause, the more valuable it is to us, and the higher the category we will assign to it.

Non-qualifying vulnerabilities

“Theoretical” vulnerabilities without any proof or demonstration of the real presence of the vulnerability
Vulnerabilities requiring physical access to a user’s browser, or a smartphone, or email account, as well as issues on rooted or jailbroken smartphones;
Reports from security scanners and other testing tools
Reports about non-implemented security “best practices” (like a lack of HSTS mechanism on client or server side, or soft token invalidation rules);
Reports about issues in third-party applications and services
Reports about missed headers or cookie flags;
Reports about configuration of our mail infrastructure (incorrect SPF records, DMARK policies, and other)
Data enumeration;
One-click authorization from emails and login CSRF via these links;
Issues that require another vulnerability to exploit, without providing that vulnerability;
Open redirects (except cases with additional impact, e.g. token hijacking);
Framing, clickjacking, tapjacking (unless you demonstrate real impact on our users);
Logout CSRF;
Self-XSS;
Captcha bypass using OCR;
Content injection issues;
Attacks based on social engineering or phishing.
Brute-force and rate-limiting attacks. We are aware of some non-optimal implementations on our side and working on the fix.

And another one important note: we'll respect your karma 'til you respect our time and work: do not send reports without precise and clear PoC; do not create several reports about one vulnerability on a different domains or different mobile platform (if it's not domain-dependant vulnerability or platform-dependent bug of course); do not send generic reports that were copied from other disclosed reports without any check that these reports at least suitable for our services and apps. In other words: be kind!

To make it easier, we’ll give you a number of examples and tell you which category they would be assigned to:

In our experience, most vulnerabilities are classified as HTML-injection or XSS. If the found vulnerability can generally not cause any damage (for example, you can only change the output of the page), then it will get the lowest category (1).
More dangerous: SQL-injection. Let's say you've found a vulnerability that "breaks" an SQL-query, but the only result is an incorrect display of content on the site. Such vulnerability will receive a rewardin the 2nd category. However, if using SQL-vulnerability an attacker can gain access to the data of one or more users, this vulnerability would rise up to the 5th category.
If a vulnerability can update data in the user profile, depending on how critical the data, we may assign a higher category, up to the 5th.
CSRF-vulnerabilities can be very dangerous - the higher the possible damage, the higher the category.

Public disclosure

We're more than happy to publicly disclose your interesting issue once it has been fixed and agreed with us to do so. Public disclosure without our permission can lead to immediate forfeiture of any reward.

Source: https://hackerone.com/bumble

Award categories

Category 5 - £ 3000

Category 4 - £ 2000

Category 3 - £ 1000

Category 2 - £ 600

Category 1 - £ 300

Non-qualifying vulnerabilities

“Theoretical” vulnerabilities without any proof or demonstration of the real presence of the vulnerability

Vulnerabilities requiring physical access to a user’s browser, or a smartphone, or email account, as well as issues on rooted or jailbroken smartphones;

Reports from security scanners and other testing tools

Reports about non-implemented security “best practices” (like a lack of HSTS mechanism on client or server side, or soft token invalidation rules);

Reports about issues in third-party applications and services

Reports about missed headers or cookie flags;

Reports about configuration of our mail infrastructure (incorrect SPF records, DMARK policies, and other)

Data enumeration;

One-click authorization from emails and login CSRF via these links;

Issues that require another vulnerability to exploit, without providing that vulnerability;

Open redirects (except cases with additional impact, e.g. token hijacking);

Framing, clickjacking, tapjacking (unless you demonstrate real impact on our users);

Logout CSRF;

Self-XSS;

Captcha bypass using OCR;

Content injection issues;

Attacks based on social engineering or phishing.

Brute-force and rate-limiting attacks. We are aware of some non-optimal implementations on our side and working on the fix.

To make it easier, we’ll give you a number of examples and tell you which category they would be assigned to:

In our experience, most vulnerabilities are classified as HTML-injection or XSS. If the found vulnerability can generally not cause any damage (for example, you can only change the output of the page), then it will get the lowest category (1).

More dangerous: SQL-injection. Let's say you've found a vulnerability that "breaks" an SQL-query, but the only result is an incorrect display of content on the site. Such vulnerability will receive a rewardin the 2nd category. However, if using SQL-vulnerability an attacker can gain access to the data of one or more users, this vulnerability would rise up to the 5th category.

If a vulnerability can update data in the user profile, depending on how critical the data, we may assign a higher category, up to the 5th.

CSRF-vulnerabilities can be very dangerous - the higher the possible damage, the higher the category.