diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 0000000000..01b10a04e0 --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,232 @@ +# Security Policy + +Thank you for helping keep the Supabase CLI and its users safe. + +## Reporting a vulnerability + +Please report suspected vulnerabilities through our HackerOne program: +. Please do not open public GitHub issues or +pull requests for security problems. + +This repository contains the Supabase CLI. It runs on a developer's machine or +in CI, starts the local development stack (`supabase start`), manages +migrations, deploys and downloads Edge Functions, and talks to the hosted +Supabase Management API on the user's behalf. There is no hosted CLI: the +target is the CLI and the local stack it starts on your own machine. Issues in +the hosted Management API itself are not tracked in this repository. Report +them through HackerOne as usual and say which API you tested. + +## What we consider a vulnerability + +In general, we want to hear about anything that lets an attacker get a CLI +user's credentials, act as that user, or run code or write files on their +machine without the user choosing to: obtaining a Supabase access token or +project secret the attacker should not have, redirecting the CLI's +credentials to a server the user did not choose, connecting to a database or +API without properly verifying who is on the other end, or turning data that +the CLI downloads into a write outside the location it was meant for. The +attacker should not need the victim's credentials or a shell on the victim's +machine, and the problem should be present in a released version of the CLI +used as documented. + +Examples of what this includes (these are illustrations, not a complete list): + +- **Theft of a CLI access token.** Getting a user to complete a CLI login, or + any other flow, in a way that hands the resulting access token to the + attacker. +- **Writes outside the intended directory.** Content the CLI downloads (for + example a function bundle or its file paths) that makes the CLI create or + overwrite files outside the project directory it was asked to write to. Show + the file actually written to a location of the attacker's choosing. +- **Secret exposure.** An access token, database password or project secret + key written to output, logs or local files in a place where the CLI is meant + to redact or omit it. +- **Credentials sent to the wrong place.** Project or repository content that + the CLI reads, such as a `.env` file or `config.toml`, that changes where the + CLI sends its access token or which server it talks to, without the user + choosing that. +- **Server identity not verified.** A CLI connection that carries credentials or + data, such as to the project database or the Management API, that does not + verify the server's TLS certificate and hostname, or that silently accepts a + weaker mode than the user asked for. This is in scope even though exploiting + it needs a network position between the user and the server: the CLI is + expected to protect those connections, so it is not the MITM exclusion + below. Show which command connects, what the attacker intercepts, and the + CLI version. + +## What we do not consider a vulnerability + +Reports that rely on the behavior below will normally be closed as +informative or not applicable. + +**By design** + +- **The local development stack is for your own workstation.** The stack that + `supabase start` runs is meant for local development. It has no + authorization or isolation layer suitable for the internet, and our + documentation says it should not be exposed publicly. Reports against a + local stack that someone has made reachable from the internet are reports + about that deployment, not about the CLI. If you believe the same issue + affects a self-hosted deployment, reproduce it using the self-hosting guide + and say so. +- **The CLI uses credentials that are already present.** If an access token is + set in the environment (`SUPABASE_ACCESS_TOKEN`) or saved by an earlier + `supabase login`, commands that call the Management API will use it without + prompting. A command that "works without logging in" on a machine or agent + session that already holds a token is not an authentication bypass. Retest in + a clean environment. +- **The CLI acts with its user's privileges.** Running SQL, pushing + migrations, deploying functions or managing secrets for projects the token + can reach is the purpose of the tool. + +**Prerequisites that make the attack pointless** + +- The attacker needs the victim's access token, database password or project + secret key. +- The attacker already has a shell, or write access to the user's home + directory, on the victim's machine. +- The attacker needs owner or admin rights on the victim's project or + organization, and the action is one those rights already allow. + +**Reports that are not evidence of a flaw** + +- **Credentials in the git history of this repository** that are revoked or no + longer valid, including values in old or commented-out config templates. + Show that a credential is live and grants access. +- **Static analysis or scanner output** with no working proof of concept + against a released CLI version. + +## Out of scope for every Supabase asset + +These are excluded program-wide (see also +). They are repeated here so +you do not need to leave this repository to find them. + +- Clickjacking on pages with no sensitive actions. +- Unauthenticated, logout and login CSRF. +- Attacks requiring MITM or physical access to a user's device. +- Attacks requiring social engineering. +- Any activity that could lead to the disruption of our service (DoS). + This means volumetric attacks, load testing and flooding. A vulnerability in + our code that lets an unprivileged attacker crash a service or exhaust + resources for other users or tenants is in scope. Denial of service that only + affects the attacker's own project, or that needs admin or owner privileges, + is not. +- Content spoofing and text injection issues without showing an attack vector, + or without being able to modify HTML/CSS. +- Email spoofing. +- Missing DNSSEC, CAA or CSP headers. +- Lack of Secure or HttpOnly flags on non-sensitive cookies. +- Dead links. +- User enumeration. + +## Known and documented behavior + +These are described in our public documentation. Please check them before +reporting. + +- **Local development is not self-hosting.** The local development guide and + the self-hosting guide describe different setups. The local stack is not + intended to be exposed outside the developer's machine. +- **`SUPABASE_ACCESS_TOKEN`** can be set in the environment to authenticate the + CLI without an interactive login, for example in CI. + +## Local development stack vs. custom setups + +We accept findings against released CLI versions used as documented. We treat +findings that need the user to misconfigure their environment first, such as by +exposing the local stack to a network, changing its `config.toml` defaults, or +running a modified CLI, as lower severity. Label your report as described in +the next section. + +## How to write a report that gets triaged quickly + +- **Say what you tested, at the top of the report and in the title.** Use one of + these labels, for example `[Local CLI] ...` in the title and a "Target" line + at the start of the description: + - **Local CLI, default configuration**: a released CLI version, and the local + stack it starts, used exactly as our documentation describes with the + default `config.toml`. Include the CLI version, how you installed it, and + your operating system. + - **Local CLI, custom configuration**: you changed `config.toml`, exposed the + local stack beyond your machine, built from a branch, or modified code. List + every change and why. We triage these lower unless the setting is one we + recommend or document. + + Reports that do not say which of the two they are about are slower to + triage, and are often closed with a request to retest. A finding that works + only on a custom configuration is not a finding against a default install. + +- **Test a real setup.** Run the released CLI binary, not only code you copied + out of it. Code reading alone is rarely enough. Static analysis findings need + a working proof of concept, and the code you cite must match the current + repository. +- **Give a short, runnable PoC.** The exact commands, any files or server + responses the attacker controls, and the output showing the impact, such as + the file written or the token received. +- **State the attacker's starting position.** What do they control (a function + in an organization the victim belongs to, a web page, a leaked key)? What + does the victim have to run? Reports that quietly assume a token already in + the environment, or a shell on the victim's machine, are our most common + reason to close. +- **Name the boundary you crossed.** Which user, project or organization could + not do this before, or which location could the attacker not write to? If + nothing was crossed, it is probably a hardening suggestion. +- **Check the docs and this file first.** If the behavior is documented, explain + why the documented design still fails. +- **Include versions.** The CLI version, installation method, operating system, + and whether any `SUPABASE_*` environment variables were set. +- **One issue per report.** Link variants of the same root cause instead of + filing each variant separately. +- **Do not send unreviewed AI output.** Reports that were not reproduced by a + human and that ignore the documentation are closed. AI-assisted analysis is + fine when you have verified the result. If an AI agent ran the CLI for you, + say whether it had logged in or had a token. +- **Respond to follow-up questions.** Reports that go quiet after we ask for a + reproduction are closed. + +## Severity + +We rate severity by realistic impact on a default setup. Issues that need user +interaction the user can see, a deliberately exposed local stack, or an +existing privilege are rated lower even when they are valid, and we may fix +them as defense in depth. + +## Testing and disclosure + +These are our program-wide rules. They also apply to AI agents and automated +tools acting on your behalf. + +**Testing** + +- Do not run automated scanners against other customers' projects. Scanners can + run up costs for our users, can disrupt services, and our own security + systems cannot tell hostile reconnaissance from research. If you want to run + an automated scanner, notify security@supabase.com first and run it only on + your own Supabase project. +- Do not attack projects that belong to other customers. +- Do not take advantage of a vulnerability you find, for example by downloading + more data than necessary to demonstrate it, or by deleting or modifying other + people's data. + +**Disclosure** + +- Do not reveal the problem to others until we have researched and fixed it and + informed affected customers. +- If you want to share your research publicly (a conference, a blog or any + other public forum), send us a draft for review and approval at least 30 days + before the publication date. Do not include data about Supabase customer + projects, customers' data, or information about Supabase employees, + contractors or partners. + +**What we promise** + +- We will respond to your report within 5 business days with our evaluation and + an expected resolution date. +- If you have followed these instructions, we will not take legal action against + you in regard to the report. +- We will handle your report with strict confidentiality and will not pass on + your personal details to third parties without your permission. +- We will keep you informed of our progress. +- In public information about the problem, we will name you as the discoverer + unless you prefer otherwise.