Faraday, Inc.

Introduction

Faraday, Inc. looks forward to working with the security community to find security vulnerabilities in order to keep our businesses and customers safe.

Please see the "Out of scope" section. There are important exclusions.

Response targets

Faraday, Inc. will make a best effort to meet the following response targets for hackers participating in our program:

• Time to first response: 2 business days
• Time to triage: 2 business days
• Time to bounty: 1 business day

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

Disclosure policy

• Please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization.
• Follow HackerOne's https://www.hackerone.com/disclosure-guidelines

Program rules

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

Test plan

Sign up at https://app.faraday.ai/signup. That gives you the API (https://api.faraday.ai) and the web app (https://app.faraday.ai).

Spend time on tenant isolation and credentials, not on missing headers. Highest-value targets:

• Other accounts' uploaded files
• Other accounts' Connection / warehouse credentials and query results
• Cloud buckets and BigQuery listed in the asset table
• Working takeover of a Faraday hostname
• Unauthenticated access to an account you do not control

In-scope hosts are the assets marked eligible for submission. An unlisted Faraday subdomain is out of scope unless you show a working takeover or it serves production customer data.

How auth works

• A JWT is bound to a user. An API key is bound to an account.
• A parent-account user can act on a subaccount.
• A user invited only to a subaccount cannot act on the parent.
• On Faraday accounts (api.faraday.ai / app.faraday.ai), every member shares the API key and can invite or remove anyone. That is intended.
• Finding your own production API key in GraphQL, REST, or the UI is intended.
• All users have the same level of privilege / access.

Cross-account leakage means two unrelated users: different emails, never invited, not in a parent/sub pair. Sign in as the attacker, confirm /v1/me or /v1/accounts/current shows that attacker identity, copy a fresh JWT, then show curl from both sides. A 200 on your own resource is not evidence. Screenshots without curl are not enough.

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 Faraday, Inc.

In scope

A report is in scope only if it demonstrates one of these, with evidence:

• Break-in. Unauthenticated or cross-user access to an account the researcher does not control. Stored XSS that runs for a victim who is not the attacker (a second account you own is enough). Working subdomain takeover of a Faraday hostname. Self-XSS and alert() in your own console do not count.
• Cross-account leakage. Two unrelated users (see "How auth works") can read or write each other's resources, including uploaded files, Connection / warehouse credentials, and query results.
• Faraday or customer secrets left public. Credentials, other customers' files, or Vault data reachable without being that customer. Catalog attributes are not secrets (see out of scope).
• Privilege gain. A lower-privilege role performing an action that only a Faraday admin should be able to do. Shared API keys and invite/remove on Faraday accounts are not privilege gain (see "How auth works").

Outbound Connections, SFTP, and webhooks are in scope for SSRF only if the worker reaches Faraday-internal or other-customer space (RFC1918, link-local, cloud metadata, another customer's store). Proof is data obtained through that SSRF.

XSS, CSRF, open redirect, clickjacking, and file-upload bugs are in scope only with impact from the list above.

Out of scope

Items below are out of scope as a standalone finding. They are in scope if you use them as a step in a chain that hits an in-scope impact (break-in, cross-account leakage, public secrets, or privilege gain).

Intended product behavior. Do not report these standalone.

• Intended auth behavior is in How auth works. Do not report it standalone.
• JWT still valid immediately after logout.
• Email verification is a product gate for an account whose inbox you control. Using that new empty account before verifying is out of scope. Registering or binding an email whose inbox you do not control (including @faraday.ai), or attaching an unverified identity onto someone else's org, is in scope.
• Connections, SFTP, and webhooks connecting to a host you configured, including nip.io / DNS names that later resolve elsewhere. The create-time host check is lexical. It does not resolve DNS.
• Faraday-provided consumer attributes, including "premium" traits, histograms, and fields that look like political, credit, or financial data. They are public at https://faraday.ai/catalog
• Frontend "enabled" flags / hidden consoles. Access control is at the API.
• Hitting account limits by sending many requests at once (this is DoS).
• Any attack whose first step is already being logged into the target account, or using that account's credentials, unless you also show impact to a different unrelated account.

Public tokens and third parties. Do not report these standalone.

• Non-secret tokens in https://app.faraday.ai/api/environment.js
• Third-party public client tokens in our JS: analytics, search, chat, auth client ids (including PostHog, Knock, Algolia, Auth0 client id, Rollbar ff5ae6124c8b4a77ae60503f62f8f213, Intercom 1pdrkobe). A finding requires using one to read or change another customer's data.
• https://faraday.atlassian.net/... is not Faraday.
• Lookalike domains of listed assets are not this program.

Standard exclusions

• Denial of Service
• Rate limiting or bruteforce on non-authenticated endpoints
• CSV / formula injection
• Permissive CORS on endpoints that use Authorization: Bearer, unless you steal a token or make a cookie-authenticated request
• Open redirect without additional security impact
• Tabnabbing, missing COOP/CSP/HttpOnly/Secure, missing TLS or SPF/DKIM/DMARC "best practices"
• MITM or physical access to a user's device
• Version banners, stack traces, descriptive error headers
• Bugs that only affect browsers more than two stable versions behind
• Public zero-days patched less than 1 month (case by case)
• Don't book a demo on https://faraday.ai while testing

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 Faraday, Inc. and our users safe!

Copyright

Copyright 2026 Faraday, Inc.