Thank you for helping keep database.dev, dbdev and their users safe.

Please report suspected vulnerabilities through our HackerOne program: https://hackerone.com/supabase. Please do not open public GitHub issues or pull requests for security problems.

This repository contains dbdev, a package manager for Postgres trusted language extensions (TLEs). It holds the database.dev package registry (a Supabase project whose accounts, organizations and packages live in database tables and are served through its API), the database.dev website, and the CLI that package authors use. The hosted registry at database.dev is a target, and so is the code in this repository that people run themselves. We accept reports for both, and we triage them differently (see "Hosted vs. self-run" below).

In general, we want to hear about anything that lets an attacker break the guarantees the registry makes to its users: acting as another account, publishing or changing a package, version or organization they do not maintain, reading data that is not meant to be public, or running script in the database.dev origin. The attacker should not need the victim's credentials, and the problem should be present on the hosted registry or in a default configuration of this code.

Examples of what this includes (these are illustrations, not a complete list):

• Stored XSS in the registry's origin. User-supplied content, such as uploaded files or package metadata, that runs script in the database.dev origin or otherwise reaches a database.dev user's session.
• Bulk exposure of account data. Listing or enumerating all accounts or profiles through the API in a way the public site does not offer, or reading fields of an account that are not shown publicly.
• Write access you should not have. Publishing, changing or deleting a package or version under an account or organization you do not belong to, or changing another account's profile or access tokens.
• Authorization errors in the database layer. Row level security policies, grants or database functions that let a caller read or write beyond what the public site and API are meant to allow. Show the data or action you gained and why it is not meant to be available to you.

These come up often. Reports that rely on them will normally be closed as informative or not applicable.

Behavior that is by design

• The registry is public. Package names, versions, source, accounts, handles and profiles are public so that anyone can find and install packages. Looking up an individual account or profile by its handle is expected. Account and organization UUIDs are not sensitive.
• Access tokens stay valid until they expire. database.dev signs in through Supabase Auth, whose access tokens are stateless JWTs. Signing out revokes the refresh token, but an access token that was already issued keeps working until it expires. Show a token working after its expiry.
• Public client-side keys. Keys that the website ships to the browser by design, such as the error-reporting (Bugsnag) API key, are meant to be public. Show that a key grants something it should not.

Prerequisites that make the attack pointless

• The attacker needs the victim's session, access token or password.
• Response tampering through your own intercepting proxy. Changing a response in your own browser changes what you see, not who you are signed in as or what the server lets you do.

Missing hardening or noise

• Repeated password-reset requests that only increase the number of emails sent. They do not make it easier to compromise an account.
• Clickjacking with no sensitive action shown being hijacked.

Reports that are not evidence of a flaw

• Script running on the storage origin. Files that users upload are served from the project's Supabase Storage URL, a different origin from database.dev. That origin holds no database.dev session or tokens, and *.supabase.co is on the Public Suffix List, so one project's subdomain cannot read another's data. A file there that only shows an alert is not account takeover. Show script running in the database.dev origin, or access to another user's data.
• SQL injection claimed from status codes. A 200 response to a tautology payload proves nothing when the opposite payload returns the same thing. Show a change in query behavior or data that the query should not return.
• Automated scanner output with no demonstrated impact, and reports that were not reproduced against a real deployment.

These are excluded program-wide (see also https://supabase.com/.well-known/security.txt). 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.

These are described in our public documentation. Please check them before reporting.

• Access tokens after sign-out. The Supabase Auth sessions guide (https://supabase.com/docs/guides/auth/sessions) explains that an access token can be used until it expires, and how applications that need a stronger guarantee can check for an active session.
• What dbdev installs. dbdev installs trusted language extensions, which are restricted to trusted languages such as SQL and PL/pgSQL. See the README and https://database.dev/docs.

Most reports concern the hosted registry and website at database.dev and its API. You can also run the registry and website locally from this repository with the Supabase CLI, as CONTRIBUTING.md describes. That setup is for development. Local default keys and settings are not findings against the hosted registry. If your finding is in the code, show that it also affects database.dev, or explain why it would affect anyone who runs the code as documented.

• Say what you tested, at the top of the report and in the title. Use one of these labels, for example [database.dev] ... in the title and a "Target" line at the start of the description:

  • database.dev: the hosted registry, website and API, using an account you own. Never act on another user's account, packages or organizations.
  • Local, default configuration: the code in this repository run exactly as CONTRIBUTING.md describes, with no changed settings. Include the commit and how you started it.
  • Local, custom configuration: you changed settings, policies or code. List every change and why. We triage these lower unless the setting is one we document.

  Reports that do not say which of the three 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 database.dev.

• Test a real deployment. Code reading alone is rarely enough. Static analysis findings, including findings in SQL migrations and RLS policies, need a working proof of concept against one of the targets above.

• Give a short, runnable PoC. Exact requests, a script or a screen recording, and the output showing the impact. For XSS, show which origin the script runs in and what it can reach.

• State the attacker's starting position. An anonymous visitor, a newly signed-up account, a package maintainer, or someone holding a victim's token?

• Name the boundary you crossed. Which account, package or organization could not do this before? Show that the data you read is not already public on database.dev. 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 commit for local tests, and the CLI version if the CLI is involved.

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

• Respond to follow-up questions. Reports that go quiet after we ask for a reproduction are closed.

We rate severity by realistic impact on the hosted registry. Exposure of data that is already public, or that is low in sensitivity, is rated lower even when the access path is valid, and we may fix such issues as defense in depth.

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.