Data security and privacy are key aspects of our service. We welcome outside help through our bounty program to make us aware of any gaps in our security.
To participate you wll need to follow a few rules:
- Be a good citizen: Do not disturb the service. Follow the terms and conditions.
- Only test with your data. Do not interact with other accounts.
- Create only few user accounts.
- If you gain access to our system, report it immediately.
- Do not publish any information regarding the vulnerability until we have fixed it.
Finally, please keep in mind this security bounty program doesn’t concern regular bugs in our application or API. We're only interested in security flaws allowing intruders to gain access to data of other users. If you wish to report a regular bug use the contact form.
Reports we're interest in
- Tampering with data of other users.
- Bypassing our API's security.
- Cross-site scripting (XSS).
- Server-side code execution.
- Website: www.opencagedata.com
Documentation, we allow non-https access, CORS
These are pre-generated static pages and the issue would need to have significant impact
- Public repositories: github.com > opencagedata
Examples of Non-Qualifying exploits
- Denial of service attacks.
- Social engineering.
Reports we don't want
SSL or DNS best practices (DNSSEC, CAA)
We review those regularly
Hardware or CPU related (e.g. BEAST, CRIME, BREACH, Lucky Thirteen)
Unless shown how they can exploited through our website or API
- Email spoofing, SPF, DMARC & DKIM
Auto-expire password or force users to regular change passwords
We believe users should use password managers and two-factor authentication these days
Choosing weak password during registration
We display a password strength estimation (weak, medium, strong) below the password field. Estimating is hard so we allow users to ignore our advise. Password must still be at least 8 characters long.
Enabling autocomplete=off attribute on password fields
Modern browsers ignore the attribute
Found OpenCage geocoding API key on a public website
We ask our users to secure their API keys, but exposure itself is not a security issue
Mass submitting contact form
There's limits by IP, address, timing, total number in place
Our reward system is flexible and doesn't have any strict upper or lower limit. The amount of the reward will depend on the severity of the vulnerability. The amount of the reward and whether or not a vulnerability qualifies will be at our sole discretion.
Rewards will be sent by bank transfer (TransferWise if the recipient is not in the Eurozone, we will not make financial rewards to countries not supported by TransferWise) once the vulnerability has been fixed and the reporter has supplied a valid invoice. All international transfer and conversion fees will be paid by the recipient.
We only award one bounty per vulnerability. If we receive multiple reports, the first one will receive the reward.
Please submit to the email address in our security.txt file.
Hall of Fame
Thanks to the following researchers who have helped us debug various issues.
Pointing to a misconfigured CNAME entry, and a specific DKIM entry
Website session handling across multiple devicesSlack security token found in a public repository (could've been used to send us messages)
How the password strength estimation on sign up page can consume too much CPU
Better hiding of software version numbers in HTTP headers
Faster account locking on failed password verification in the user dashboard (when user is already signed in)
Wiki page on public repositories was editable; On incomplete 2fa setup users were able to lock themselves out
HTTP Header misconfiguration on our blog
Better password advice
Lower limits for storing user-supplied account data
iframing protection on one of our blogs was not active after a framework upgrade
Better limits for users validating discount codes / creating additional keys