inDrive

Security is a top priority at inDrive. If you believe you've found a security bug in our in-scope applications or infrastructure, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery.

Also, subscribe to our news channel on Telegram.

At these links [1],[2] you will find a CSV files containing the endpoints to be scanned.

The scope of this inDrive’s Vulnerability Disclosure Program Policy is limited to searching for technical vulnerabilities in the company's services and official mobile applications.

#Update to the Scope Policy (from 09/09/2025)

inDrive is not only about ride-hailing - we also contribute to education, sports, environmental initiatives, and other social projects. To make our bug bounty program clearer, we divide the scope into Core and Non-core services:

• Core services are directly connected to our main app infrastructure (backend, frontend resources). E.g., no-gw-cf.<region>.aws.indriverapp.com, couriers.indrive.com. They can be identified by using the filter Technology: Core in the Scope page. Rewards for vulnerabilities are listed in the “Price (for Core services)” column in the Reward payment section.
• Non-core services are additional projects of inDrive, such as web resources related to social, non-profit, experimental initiatives and partner integrations. They can be identified by using the asset filter Technology: Non-core in the Scope page. Rewards for vulnerabilities are listed in the “Price (for Non-core services)” column in the Reward payment section.

If you are unsure, or cannot find the relevant asset in our scope, please submit your report anyway. Our team will review it during triage and clarify whether the service belongs to Core or Non-core.

#We will not pay a reward (and we will be really upset) if we detect:

• Social engineering directed at the company's employees
• Attempt to access arbitrary user's account or data or another vulnerability post- exploitation not required to demonstrate the bug presence
• Distributed network/request flooding and other resource exhaustion attacks. Automated scanning tools must be limited to 5 request per second (300 requests per minute) to one target host summing up all tools and threads running in parallel and must not exceed 5 parallel requests at the same time (5 threads).

Please use your own accounts, phone numbers, etc to conduct your research. Do not try to gain access to others' accounts or any confidential information. When testing the feedback functionality, sending a message to technical support, etc., be sure to specify the subject Test and use hacker email alias

#We do not initiate security investigations regarding:

• Messages from security scanners and other automated systems without clear PoC and impact;
• Vulnerability reports based on software/protocol versions not indicating the actual usage/exploitation;
• Reports about the absence of a protection mechanism or non-compliance with recommendations (for example, the absence of a CSRF token) without indicating real negative consequences;
• Self-XSS;
• Framing;
• Social engineering;
• Clickjacking;
• SPF/DKIM/DMARC issues;
• Man-in-the-Middle attacks
• Vulnerabilities in partner services and products that do not directly affect the security of the company's services.
• Infrastructure vulnerabilities, including: * Server configuration issues (e.g. open ports, TLS versions, etc.) * Issues related to SSL certificates * DNS configuration issues
• Google API key(for google maps)

#Strictly prohibited actions:

• DoS / DDoS attacks;
• Threats/harm to company employees.

#How do I submit a bug report?

A bug report must give a detailed description of the discovered vulnerability and brief steps to reproduce it, or a working proof-of-concept. Video and screenshots can illustrate bug report, but can not replace it.

If you do not describe the vulnerability in sufficient detail, the discovery process is significantly prolonged and that doesn't help anybody. It's also very desirable if researcher can explain how exactly he or she found a given vulnerability.

#How are bug reports examined?

Reports about vulnerabilities are examined by our security analysts. Our analysis is always based on worst case exploitation of the vulnerability, as is the reward we pay.

Reports are reviewed within 15 days (this is a maximum period - we'll probably respond sooner). If you prefer to remain anonymous, we recommend using an alias when submitting bug reports.

#Participating reports

Only reports reported via bug bounty platform interface may be considered for a bounty. A date/time of report on bug bounty platform is considered as a date/time of the report.

#Duplicate reports

Different exploitation vectors for the same bug or similar bugs may be considered duplicating if the security team believes information provided for a single vector/bug is enough to fix all vectors or bugs reported.

Report for known or duplicating vulnerability is considered as Duplicate. Duplicate reports are not eligible for monetary reward. Report can be either a duplicate of another report from any bug bounty platform or a duplicate of the problem internally tracked by inDrive security team. Usually, access to the original report or some information from the internal task tracker is provided to the reporter of Duplicate. In some cases information may not be provided, if a Duplicate contains less information or less critical exploitation vector than the original report.

The report is considered as a duplicated to another report from any bug bounty platform, if there is original report is in "New" or "Triaged" state with an earlier report date/time or lower report number of if it updates the report in "N/A" or "Need more info" state and original report is in "N/A" or "Need more info" state for less than 1 week or sufficient information is provided in original report by researcher since the report is transferred to "N/A" or "Need more info" state.

The report is considered as a duplicate to an internal task if there is a task in the internal task tracker which is tracked by the inDrive security team at the time of the duplicate report. Also, public 0-day/1-day vulnerabilities may be considered as a duplicate within a few days after vulnerability details publication, if the vulnerability is known to our team from public sources and we are working to mitigate or patch it.

#Invalid reports

Report in "N/A" or "Need more info" state which is stale in this state for more than a week without sufficient new information provided is considered as invalid and does not participate in bug bounty.

#Reward payment

We will pay you a reward if you are the first person to report a given vulnerability.

The bounty decision will be made within 30 days after triage (this is a maximum period - we'll probably award sooner). A message will appear in your bug report, indicating that the vulnerability you reported has been confirmed and a reward has been granted.

Payments are made through HackerOne.

*self-XSS, XSS specific to non-common browsers (e.g. IE), blocked by CSP and another vectors without proven script execution are usually accepted without bounty. Unused subdomain takeover is considered under same severity / conditions as parent domain XSS.

**We temporarily do not accept reports on Social Media links(instagram, twitter, facebook)