Bumble and Badoo vulnerability disclosure program

We pay for all newfound vulnerabilities in Bumble, Badoo, and Fruitz products.

Vulnerabilities will be ranked depending on their severity. The Bumble jury determines the severity of the vulnerability.

Where to look for vulnerabilities for Bumble:

In scope:

• (www).bumble.com

• bumble.com (+mobile web version)

• bma.bumble.com

• Bumble mobile application (App Store, Google Play)

Out of scope:

• blog.bumble.com

• thebeehive.bumble.com

Where to look for vulnerabilities for Badoo:

• badoo.com (+mobile web version)

• eu1.badoo.com

• us1.badoo.com

• corp.badoo.com

• m.badoo.com

• meu1.badoo.com

• mus1.badoo.com

• chatdate.app

• heyfiesta.com

• blendr.com

• bma.badoo.com

• badoocdn.com

• translate.badoo.com

• ccardseu1.badoo.com

• ccardsus1.badoo.com

• Badoo Mobile Applications (App Store, Google Play).

Where to look for vulnerabilities for Fruitz:

• Fruitz mobile application (App Store, Google Play)

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

• Clickjacking. We understand the OWASP explanation of this but don't think that static page with no user interaction can lead to security compromise.

• “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;

• Captcha bypass using OCR;

• 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 (Low).

• 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 could receive a reward in Medium 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 Critical 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 Critical.

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.