Introduction

Welcome to the Doctolib Bug Bounty program! We're excited to offer a way for the security community to help us find and fix vulnerabilities on our platform.

Our mission, as a leading healthcare service provider in Europe, is to ensure the utmost confidentiality, integrity, and availability of our users' data. We are proud to invite skilled hunters to assist us in identifying vulnerabilities and strengthen the security of our platform.

We are dedicated to collaborating with the most brilliant minds in the industry to detect potential security gaps and to remain ahead of emerging threats. Our bug bounty program is a crucial element of our security strategy, and we are thrilled to make it available to the public.

Thank you for your consideration of our program. If you have any questions contact us at security@doctolib.com

☑️ Eligibility and Rules

To ensure the safety and security of all parties involved, we have established the following cumulative eligibility rules for our bug bounty program:

• You must be the initial discoverer of a vulnerability and the vulnerability must not have been previously detected in our internal vulnerability tracking system.
• The vulnerability must be reported exclusively through our designated reporting platform, yeswehack.com.
• The report should include a clear textual description of the vulnerability, a step-by-step procedure to reproduce the issue, and any necessary attachments such as screenshots or proof of concept code.
• The report should also include a clear explanation of the impact of the vulnerability's exploitation.
• You must comply with the testing precautions.
• No phishing on users and employees.
• All testing made under the Doctolib Bug Bounty program must not have any negative impact on the care team or patients, in accordance with the “testing precautions” below.

Failure to comply with the preceding rules will result in the rejection of your report.

💵 Reward

We consider that spotting big bugs requires big rewards. For this reason, we propose a specific and detailed reward structure to ensure that there is no confusion or ambiguity in the allocation of the rewards. 

• Personal data typology defines 5 typologies of data.
• The reward grid offer rewards based on the typology of the data and the business impact 

Personal data typology

We have developed an in-house system for categorizing personal data based on its level of sensitivity and re-identification risk. This system enables us to precisely assess the severity of any vulnerability identified, and ensure that our bug bounty program rewards are tailored to the level of risk posed by the vulnerability. 

GDPR classification	Bug Bounty typology	Description and example
Personal Information	Type 1	Data with a low risk of re-identification: - technical IDs - pseudonymized data
Personal Information	Type 2	Data where medium identification needs an external data: - IP address - phone number - personal address
Personal Information	Type 3	Data with an indisputable risk of re-identification - first name and last name - email address
Personal Health Information	Type 4	Data that can provide information insights into a person's health status (e.g.: appointments data)
Personal Health Information (and any other “special category of data” as defined in GDPR Article 9)	Type 5	Any information that is collected about a person's health status, such as their vital signs, test results, and medical diagnoses. This information is typically collected by healthcare providers and is used to diagnose and treat medical conditions, monitor treatment effectiveness, and track disease progression.

🎯 The reward grid

This reward grid has been designed to provide clear guidelines on the types of vulnerabilities we are interested in, and the corresponding rewards for each. If you have any questions about our reward grid, we encourage you to ask for clarification by email.

Exploit (category)	Exploit (detail)	Impact on Doctolib’s users (pro and patient): Group of users (ex: one http request to access several non-relative users)	Impact on Doctolib’s users (pro and patient): Any single given user account randomly chosen (ex: IDOR that require to do a HTTP request for each user)
Access to PII	Access to "type 1" data	Medium	Low
Access to PII	Access to "type 2" data	High	High
Access to PII	Access to "type 3" data	High	High
Access to PII	Access to "type 4" data	Critical	Critical
Access to PII	Access to "type 5" data	Critical (sp. scenario)	Critical
Manipulate our Patient app to send emails from Doctolib server	Sophisticated (ex: insert images in Doctolib emails)	High	Medium (possibly high at our discretion)
Manipulate our Patient app to send emails from Doctolib server	Simple link	High	Medium
Manipulate our Patient app to send SMS from "Doctolib"	Full control of the content	High	High
Manipulate our Patient app to send emails from Doctolib server	Link injection	High	High
Cross-site scripting	Access to DOM with user action required (ex: reflected xss)	High	Medium

Note that the display of healthcare professional data (such as professional phone number) is normal functioning of our product. As mentioned in our Privacy Policy, Doctolib uses specialized service providers to feed its public directory (see our privacy policy on this matter: https://info.doctolib.fr/politique-de-protection-des-donnees-personnelles/).

💰The special scenario

Special bonuses are the most important reward for security vulnerabilities that pose a significant risk to our platform and cause us significant concern. If your critical vulnerability fall under any of the following scenario, you will be rewarded with :

50 000 €

(instead of 20 000€)

🚨The “game over” scenario

Ability to gain privileges on any production instance of our Ruby on Rails monolith, to read or write the production environment variable "SECURITY_BUG_BOUNTY_DOCTOLIB_IS_PWN," which contains the URL of a webhook that triggers a security crisis. RCE in other infrastructure components do not qualify as a "game over" scenario.

🎯The “One shot” scenario

Ability to use vulnerability at the application level to dump the entire patient base of any given Doctor (ex: export of the patient base of any doctor randomly chosen) with a reasonably small amount of request (ex: IDOR that allows to extract a partial amount of the patient base fall under regular “critical”). 

Please note that our detection rules are not designed to filter out bug bounty user agents, as we believe that would be unfair. We encourage all participants to follow our testing precautions below and to act in an ethical and responsible manner.

⛑ Testing precautions

We ask that you conduct your bug bounty activities in a way that does not impact the experience of our care teams or patients. If you are interested in testing something that may be considered dangerous, we encourage you to contact us by email, and we will work with you to provide the necessary testing conditions. 

🧑‍⚕️If you want to test appointment booking, do not use your real Doctolib account. Please 

• DON'T use your Doctolib personal account. Please create a test account with fake data. The firstname, lastname, birthdate, phone and email will be in the patient base of this test Doctor and security researcher from our private bug bounty will be able to access it.
• make an appointment with our fake doctor.
• The code to book an appointment with Dr Albertus Boulenfunkierchenblah is 42

We strive to provide optimal testing conditions (e.g. no VPN required) but failure to adhere to the stated precautions and causing business issues will result in disqualification from the bug bounty program without reward.

TLDR;

• Use the "BugBounty/42 (YWH)" string to the user-agent (or read the exception below)
• Avoid using automated tools, or use them the gentle way (Max 10 requests per second).

Our applications are supposed to be hardened, so you should be able to perform scans. We only ask you to add the "BugBounty/42 (YWH)" string to the user-agent header in your requests.  This is important because in case your traffic has an impact on the quality of our services, we will temporarily block the bug bounty requests based on this user agent.

User agent exemption 

The specific user agent is required for heavy traffic. However, for lighter traffic when searching for bugs, it is acceptable to temporarily use a regular user agent if you believe it has an impact on your research. This must remain exceptional.

📣 Communication and Feedback

We encourage all hunters to report any vulnerabilities they find in our system, and we provide clear channels for communication and feedback. If you believe you have discovered a vulnerability, we recommend that you report it through the YesWeHack platform, where we run our bug bounty program.

You can contact us by email at security@doctolib.com for any reason, such as requesting testing conditions or asking for clarification on our program rules.

😇 ETHICS

• You must not leak, manipulate, or destroy any user data.
• You must not be a former or current employee of Doctolib or one of its contractors.
• No vulnerability disclosure, including partial is allowed.

Free features for healthcare professionals

Certain features of Doctolib Pro are free and require regular identity verification (for example, the Siilo app). These features are within the scope of this public bug bounty program.

Other free features require verification of the right to practice through a government-issued ID document (e.g., Carte Professionnelle de Santé). These features are outside the scope of this public bug bounty program.

Hints

Here, you'll find some explanations regarding the business logic behind certain features. These explanations are provided to help you save time during your research, giving you a clearer focus.

Medical Data Synchronization process

The medical data synchronization process is about updating appointment data or patient messaging data in order to link them an account. Here’s what you need to know:

• Offline Appointments / patient messaging:
  • These are appointments or patient messaging directly created by the doctor and aren’t connected to any online user account.
  • The goal of the synchronization process is to link the offline data to an account.
• Relative Appointments / patient messaging:
  • When a user (= a caregiver) books an appointment or send a patient messaging for someone else (= a relative). The appointment / patient messaging are linked to the online account of the caregiver but not yet to the one of the relative.
  • The goal of the synchronization process is to link the relative data to the account of the relative.

The email and/or phone number given at the time of the appointment booking or the patient messaging creation will get a link. Clicking this link starts the synchronization process. Here are the requirement to successfully pass the synchronisation process:

• You need to have access to the email and/or phone number tied to the appointment / patient messaging. For appointment only, if there’s no email, then only the phone number matters and you need to know the 3 first letter of the patient name. The phone number (and the email if not empty) must match with the user account.
• For relative appointment / patient messaging, the identity data tied to the appointment / patient messaging must match with the account of the relative. This includes first name, last name, and date of birth. Please note that the identity match is here to prevent accidental synchronization but the ability to brute-force the identity will not be rewarded.

Here is a hash for the record

1b46d17e91790a31842ba5f9977c72356abbde2b8e93a0aef92f556bc5e78eab