Home Original page

OpenCage Security Bounty Program

Overview

Data security and privacy are key aspects of our service as laid out in our Security Policy.

We welcome outside help through our bounty program to make us aware of any gaps in our security.

To participate you will 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.

Please keep in mind this security bounty program doesn’t concern regular bugs in our application or APIs. 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.

We treat reports to multiple companies at the same time and newsletters as informative only (not a report). If we see no testing was done on our systems to confirm it applies, then no reward is possible. We reply once asking to unsubscribe us. If such emails continue we'll eventually block the email sender.

Reports we're interested in

  • Tampering with data of other users.
  • Bypassing our API's security.
  • Cross-site scripting (XSS).
  • Server-side code execution.

In scope

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, MTA STS)
  • 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
  • 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

  • Two factor code (TOTP) valid longer than 30 seconds

    We allow one extra timestep to account for transmission delay.

  • Email addresses extracted from stealer logs. Those aren't an indication of leaks from our systems, but originate from malware on users' computers. We're happy to disable any affected accounts but lists we received so far didn't match email addresses in our records. The lists seem to be low quality, very old (already dealt with years ago) or possibly fake.
  • Two-factor code don't expire after exactly 30 seconds

    RTC6238 allows a little extra time in case internet connection is slow

  • Reports related to the Geomob site.

    It is not part of our core business.

Rewards

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.

Report submission

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.

  • Abhi Noob Researcher

    Made us aware of not following data sanitization best practice in a geocoding plugin

  • Abhay Kumar

    HTTP parameter pollution of our geosearch service - while not a security issue there was potential for user confusion.

  • Takshal Patel

    When pasting spreadsheet data the maximum size validation did't account of unicode byte size.

  • Vigo

    For rate limiting treat all on URLs containing a token parameter like POST requests.

  • Vigo

    User can change their email and make a typo. Repeat the new email on screen and via email.

  • Vigo

    During account registration correcting an email address is an account deletion. Add more protection on the action. Only worked on unconfirmed accounts.

  • Nishant Lungare

    Strict Cross-Origin-Opener-Policy to prevent a parent browser window from manipulating current window location, especially during OAuth flow.

  • Michal Biesiada

    security.txt and related encryption key pair date expired.

  • -

    End all user sessions after user disconnects OAuth service in their Google account.

  • Gaurav Wagh

    Subdomain pointed to a third-party service we no longer used. That service didn't enforce ssh login rate limiting.

  • Kamil Rahuman

    Dockerfile was accessible on our blog.

  • Sankalpa Baral

    Rapid resetting of own password could lead to race condition (and user confusion)

  • Om Dubey

    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.

  • Srikar V

    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).

  • Fahimhusain Raydurg

    Optimiztion of Content-Security-Policy settings

  • Swapnil Kothawade

    The wiki pages of perl-Geo-Address-Formatter were editable.

  • Burhan Chhotaudepur

    Better limits for users validating discount codes

  • Brandon Roldan

    Limits against brute-forcing to create additional keys

  • Fahimhusain Raydurg

    Providing huge amount of feedback text during account deletion caused website to become unresponsive

  • Ranjeet Singh

    Tracing a possible email related log4j issue (turned out to be harmless and outside our systems)

  • Shivam Pandey

    Website session handling across multiple devices; Slack security token found in a public repository (could've been used to send us messages)

  • Aman Rai

    How the password strength estimation on sign up page can consume too much CPU

  • Virendra Tiwari

    Better hiding of software version numbers in HTTP headers

  • Armanul Miraz

    Better hiding of software version numbers in HTTP headers

  • Kunal Mishra

    Faster account locking on failed password verification in the user dashboard (when user is already signed in)

  • Tinu Tomy

    Wiki page on public repositories was editable; On incomplete 2FA setup users were able to lock themselves out

  • Anurag Muley

    HTTP Header misconfiguration on our blog

  • Nishant

    Better password advice

  • Nitin Gavhane

    Lower limits for storing user-supplied account data

  • Pritam Mukherjee

    Iframing protection on one of our blogs was not active after a framework upgrade

  • Ayham Alhamza

    Open redirection

  • Swapnil Patil

    CSRF bug

  • Nessim Jerbi

    Pointing to a misconfigured CNAME entry, and a specific DKIM entry

  • Rishikesh KS

    Host header injection