LaunchDarkly Program Policy

At LaunchDarkly, our vision is to create a world in which software releases are safe and unceremonious. LaunchDarkly gives product delivery teams the safeguards to move fast without breaking things through the use of feature flags.

As a platform that our users trust to handle their user and customer data, application security and data protection are crucially important to us. LaunchDarkly looks forward to working with the security community to find security vulnerabilities in order to keep our businesses and customers safe.

Response Targets

LaunchDarkly will make a best effort to meet the following response targets for hackers participating in our program:

• Time to first response (from report submit) - 2 business days
• Time to triage (from report submit) - 5 business days
• Time to bounty (from triage) - 10 business days

We’ll try to keep you informed about our progress throughout the process.

Program Rules

• All testing should be done on accounts associated with an email address on the wearehackerone.com domain. Once you have confirmed your email address, accounts on this domain will automatically be activated on a plan that provides access to all features on the LaunchDarkly platform. These accounts must only be used for testing for the purposes of the LaunchDarkly Bug Bounty Program. If you would like an account for other purposes, you may sign up for another account with a different email address.
  • If you need to test features on accounts without access to these features, you may create a trial account using a different email address, as long as it contains the string hackerone (for easy identification as a tester account). For example, you can create an account as [email protected]. Note that these accounts will have a regular trial that will expire.
• Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.
• Submit one vulnerability per-report, unless you need to chain vulnerabilities to provide impact.
• When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).
• Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.
• Social engineering (e.g. phishing, vishing, smishing) is prohibited.
• Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with the explicit permission of the account holder.

Disclosure Policy

• Please do not discuss any vulnerabilities (even resolved ones) outside of the program without express consent from the organization. Follow HackerOne's disclosure guidelines.
• Please do not share any information about LaunchDarkly's functionality, as researchers may have access to unreleased features.

Testing and Guidance

LaunchDarkly frontend (app.launchdarkly.com)

What it does: The main LaunchDarkly application and point of entry. LaunchDarkly customers use this interface to log into the application and manage feature flags, context types, segments, and so on. Admin level users may also manage their LaunchDarkly organization (i.e. users, roles, environments) from this interface.

How to test: Please create an account with your @wearehackerone.com email address in order to receive an account with full access to all features on the LaunchDarkly platform. Documentation for how to use LaunchDarkly may be found on our docs website.

What to look for: In addition to the usual web vulnerability concerns, we'd be particularly interested in any findings related to:

• Improper authentication/access control
• User privilege escalation to perform actions not defined in role
• XSS/SSRF in user input fields

Additionally, we'd like to call special attention to the following application components that we recently released for general availability:

• Custom Contexts: We've recently updated the platform's user model to support customer-defined contexts (e.g. users, devices, business units, organizations) for flag targeting. While this change in the underlying model should generally be a 1 for 1 replacement (i.e., users -> custom contexts), we'd be interested to see if the new infrastructure, UI components, etc. created to support custom contexts are susceptible to any web application vulnerabilities or business logic errors. For more details, see the following docs:
  • Introduction to contexts
  • Best practices for upgrading users to contexts
• Experimentation: In 2022 we launched a refresh our experimentation offering which allows customers to use feature flags in conjunction with events tracking to evaluate how feature flags affect key performance metrics. We'd be interested in any potential vulnerabilities or logic errors that arise from creating and running experiments within the platform.

What it runs on: React/NodeJS

LaunchDarkly APIs (app.launchdarkly.com/api/v2/)

What it does: Provides the backend APIs for the LaunchDarkly application

How to test: Our external-facing API documentation may be found here: API docs

The /api/v2/ and /internal/ subroutes are customer-facing APIs and require either a valid ldso session cookie or an access token in the Authorization header for authentication. You may create an access token from the Account Settings page in the UI for use in API testing. If you prefer to use the session cookie, the ldso token may be retrieved from your own browser after logging into the UI.

Conversely, the /private/ APIs are not meant to allow authentication to any non-LaunchDarkly users and use a separate authentication mechanism. Any cases where these endpoints are improperly accessible are worthy of note.

What to look for: In additional to the usual API vulnerability concerns, we'd be particularly interested in any findings related to:

• Unauthenticated/unauthorized access to APIs
• APIs returning unexpected data (e.g. data from different accounts/environments, data the user role should not have access to, etc.)
• Handler logic errors that cause unexpected/undefined behavior

What it runs on: Golang

LaunchDarkly SDKs

What they do: SDKs are integrated into customer applications to evaluate LaunchDarkly feature flags the application. LaunchDarkly provides a wide range of SDKs for various languages and platforms, documented here: SDK docs

How to test: We encourage researchers to integrate SDKs with custom applications and test the communication between the SDKs and LaunchDarkly's servers (see more details in the streamer/event recorder sections below). You'll need to generate an SDK key/client ID from the UI in order to initialize the SDK's connection with LaunchDarkly. We'd be interested in any general API vulnerability findings as well as any handler logic vulnerabilities that you may find.

Additionally, our SDKs are open source and are available on Github (e.g. React client SDK). We encourage researchers to dig into the open source code if interested. However, we will not be accepting the following types of findings:

• Findings related to non-SDK repositories (i.e., repos not ending in -sdk)
• Vulnerability/dependency scan results of our source code. Please try and dig into our source code more deeply than just reporting a scan result that we may already be aware of.

What it runs on: The SDKs cover a wide range of languages and platforms depending on the SDK, see the docs referenced above for details.

Streamer (stream.launchdarkly.com)

What this does: Streamer provides flag information for server and client SDKs for flag evaluation. SDKs maintain connectivity with distributed streamer nodes and receive flag updates as changes are made in the platform in real time, allowing end user clients to react instantaneously and update the application accordingly.

How to test: streamer.launchdarkly.com exposes a set of routes for retrieving flag data depending on whether the SDK is client or server-side (see the distinction here: client vs server SDKs).

What to look for: Generally, we're looking for ways that attackers could exploit our flag evaluation logic to improperly retrieve flag information meant for other users. Client-side SDKs are specifically meant to prevent attackers from accessing things such as flag evaluation rules due to the untrusted nature of client devices, so any improper handling/exposure of this data may be considered noteworthy.

What it runs on: Golang

Event Recorder (events.launchdarkly.com)

What this does: Once flags are evaluated by the client/server SDKs, these SDKs will record and send events to events.launchdarkly.com for metrics collection. This allows customers to collect data about things such as which flags are being evaluated, how many times flags are evaluated, which contexts are being targeted, etc.

How to test: events.launchdarkly.com exposes a set of routes for handling and processing event data. No authentication is needed to access these endpoints, but the endpoint may expect certain metadata to be considered valid input.

What to look for: We'd be interested in ways that attackers may want to exploit our event recording mechanisms.

What it runs on: Golang

Docs Site (docs.launchdarkly.com)

What this does: Static site hosting LaunchDarkly documentation (i.e. installation/user/admin guides, API references, etc.)

What to look for: The site is mostly static, but there are user input fields (e.g. search bar) that we'd want to ensure are not vulnerable to any XSS or other injection vulnerablities. The site also makes cross-origin requests to app.launchdarkly.com, so any potential CSRF vulnerabilities would be noteworthy.

What it runs on: React/NodeJS

Third Party Integrations (not currently in scope)

What these do: LaunchDarkly provides a handful of third party integrations for use by customers. While these aren't considered in scope today, we are working on refining our testing methodologies for these integrations and plan on making these available for testing in our program in the future.

Rewards

Our rewards are based on severity per CVSS (the Common Vulnerability Scoring Standard). Please note these are general guidelines, and reward decisions are up to the discretion of LaunchDarkly.

Known issues

Please note that the following issues are considered known risks and will not be eligible for bounties:

• Rate limiting on account verification and forgot password pages

Out of scope vulnerabilities

When reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:

• Clickjacking on pages with no sensitive actions
• Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions
• Attacks requiring MITM or physical access to a user's device.
• Previously known vulnerable libraries without a working Proof of Concept.
• Comma Separated Values (CSV) injection without demonstrating a vulnerability specific to the LaunchDarkly platform. Vulnerabilities related to Excel interpreting and executing injected text are not in scope.
• Missing best practices in SSL/TLS configuration.
• Any activity that could lead to the disruption of our service (DoS).
• Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS
• Rate limiting or bruteforce issues on non-authentication endpoints
• Missing best practices in Content Security Policy.
• Missing HttpOnly or Secure flags on cookies, except the ldso cookie.
• Missing email best practices (Invalid, incomplete or missing SPF/DKIM/DMARC records, etc.)
• Vulnerabilities only affecting users of outdated or unpatched browsers [Less than 2 stable versions behind the latest released stable version]
• Vulnerabilities only affecting users of uncommonly-used browser extensions (eg, an extension designed to find redirect URLs embedded in the URL are designed to create open redirects on all URLs)
• Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors).
• Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis.
• Tabnabbing
• Open redirect - unless an additional security impact can be demonstrated
• Issues that require unlikely user interaction
• Client-side SDK keys (used by the JS SDK and mobile SDKs) are not required to be kept secret. Please don’t report that these are visible in a properly-deployed application of the service.
• Client-side keys or tokens used on our website that are also not required to be kept secret. Examples include: Algolia search API key, TrackJS analytics token, etc.
• Jira ServiceDesk allowing public registration
• Verification email inbox spam
• HTML injection on text fields within the app or emails generated by the application
• Password reset link not expiring if email address changed
• Vulnerability scans / dependency scans on open source repositories
• Open source Github findings not related to our client and server SDKs (i.e., repos not suffixed by -sdk)

Launchdarkly credentials that have been leaked are only eligible if:

• Customer credentials that were leaked through some action or inaction of LaunchDarkly (ie, a customer checking their own API token into Github would not be eligible)
• They are not meant to be made public (the browser SDK operates using a token that is intended to be embedded in publicly-exposed source code)
• Tokens belonging to LaunchDarkly-controlled accounts, that have the "bountyEligible": true value in the /api/v2/caller-identity response. This excludes testing accounts, and other accounts with no valuable data.

Safe Harbor

Any activities conducted in a manner consistent with this policy will be considered authorized conduct and we will not initiate legal action against you. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will take steps to make it known that your actions were conducted in compliance with this policy.

Thank you for helping keep LaunchDarkly and our users safe!