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 interested 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
Issues concerning: status.opencagedata.com
The site is hosted by a third party and outside of our control
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
Passwords over 512 character length cause error
The error is instant, thus no DOS effect
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 (Wise if the recipient is not in the Eurozone, we will not make financial rewards to countries not supported by Wise) 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.
Made us aware we were not adequately handling all aspects of the hand-off from Stripe post-purchase.
Md Sojib Islam Nirob
Setting email address as password is insecure and we block that on signup and update email feature. We forgot to do the same on reset password feature.
Visiting the enable-two-factor directly in a later session would display the already used initial setup (QR) code again.
Ranjeet Kumar Singh
When multiple email change processes were initiated a user could be confused which email confirmation link to click (emails are already unique and contain all information to distinguish them).
Optimiztion of Content-Security-Policy settings
The wiki pages of perl-Geo-Address-Formatter were editable.
Better limits for users validating discount codes
Limits against brute-forcing to create additional keys
Providing huge amount of feedback text during account deletion caused website to become unresponsive
Tracing a possible email related log4j issue (turned out to be harmless and outside our systems)
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