Supabase is an open source Firebase alternative. We allow developers to build in a weekend, scale to millions.

At Supabase, we consider the security of our systems a top priority. But no matter how much effort we put into system security, there can still be vulnerabilities present.

If you discover a vulnerability, we would like to know about it so we can take steps to address it as quickly as possible. We would like to ask you to help us better protect our clients and our systems.

What we promise:

• We will respond to your report within 7 business days with our evaluation of the report and an expected resolution date.
• If you have followed the instructions below, we will not take any legal action against you in regard to the report.
• We will handle your report with strict confidentiality, and not pass on your personal details to third parties without your permission.
• We will keep you informed of the progress towards resolving the problem.
• In the public information concerning the problem reported, we will give your name as the discoverer of the problem (unless you desire otherwise).
• Fair compensation based on our stated rewards and in line with the assessed severity.

Program Rules

At Supabase our number one priority is our customers and the security of their data. We appreciate your help in this mission and being deliberate in your research, ensuring you adhere to the program scope and making every effort to not directly impact our users.

• Read the program scope
• Check that you are engaging with Supabase and not with a Supabase customer
• Check the Supabase changelog for recently released features
• When in doubt, reach out to us through [email protected]

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 disclosure guidelines.

Performing your research

• Do not impact other users with your testing, this includes testing vulnerabilities in projects or organizations you do not own. If you are attempting to find an authorization bypass, you must use accounts you own.
• We recommend creating an account with your @wearehackerone.com email address. For testing cross project/organization issues, you can create a second account using email aliasing, https://docs.hackerone.com/hackers/hacker-email-alias.html#multiple-aliases
• Clearly identifying accounts that are associated with bounty research helps our teams to differentiate between possibly malicious activity and that of researchers involved in our Bug Bounty program. Please note that adding your HackerOne email address does not provide any exemptions to our Terms of Service or permit you to act beyond our bounty rules and scope.
• We STRONGLY recommend setting an HTTP header identifying your H1 account. X-SUPABASE-VDP: {H1 HANDLE}
• Do NOT blindly run automated tools or simply submit the output from an automated tool that you have not manually verified.

Handling personally identifiable information (PII)

If you come across PII during the course of your research or vulnerability exploitation, stop, and report the issue to us immediately. Any attempts to leak more data than is necessary to demonstrate a vulnerability will be considered a breach of program rules. Do not store extracted PII, as soon as you have reported the issue to us, destroy the data.

When reporting, redact PII data, if we can reproduce your vulnerability report, we can see what PII is being leaked. You do not need to include this information in your report.

If you can show that you can access the records of another user, stop there. You do not need to attempt to access the records of a thousand users just to prove a point.

The following is never allowed

• Directly attacking or impacting Supabase customers.
  • Remember, Supabase provides a platform for customers to host their data / function / storage. Double check that you are testing against Supabase and NOT a Supabase customer.
• DDoS
• Spamming content
• Large-scale vulnerability scanners, scrappers or automated tools that produce excessive amounts of traffic
• Attacking our support staff (attempts at social engineering)

Reporting Vulnerabilities

What to include in reports, reproduction steps, screenshots etc.

When reporting a vulnerability, the more information you can provide the better. Reports with clear reproduction steps and screenshots are highly valued.

Report your vulnerabilities as early as possible. Before attempting to “escalate” privileges or perform any lateral movement, report your vulnerability to us. Attempts to perform unauthorised lateral movement, access data that is not yours or otherwise performing anything that is not within the necessary scope to demonstrate that a vulnerability exists, may lead to us treating your report as ineligible for bounty.

In order to protect our customers, do not reveal the problem to others until we have researched, addressed and informed our affected customers.

We will consider disclosure requests on a case by case basis.

If you want to publicly share your research about Supabase at a conference, in a blog or any other public forum, you should request disclosure, share a draft with us for review and approval at least 30 days prior to the publication date. Please note that the following should not be included:

• Data regarding any Supabase customer projects
• Supabase customers' data
• information about Supabase employees, contractors or partners

Response Targets

Supabase makes every effort to meet the following SLAs for hackers participating in our program:

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

---

Out of scope targets

All customer domains under *.supabase.co

Reports of "SQLi" on api.supabase.com/platform/pg-meta/{PROJECT_ID}/query. This end-point intentionally accepts raw SQL queries and forms part of core functionality offered by the Supabase dashboard. Reports will be treated as Not Applicable.

Out of scope vulnerabilities

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

• Social engineering support
• 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.
• Missing best practices in SSL/TLS configuration.
• Any activity that could lead to the disruption of our service (DoS).
• Rate limiting or bruteforce issues on non-authentication endpoints
• Missing best practices in Content Security Policy.
• Missing HttpOnly or Secure flags on cookies
• Configuration of or missing security headers.
• 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]
• Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g., stack traces, application or server errors).
• Tabnabbing
• Issues that require unlikely user interaction
• Improper logout functionality and improper session timeout.
• CORS misconfiguration without an exploitation scenario
• Broken link hijacking
• Lack of jailbreak detection in mobile apps.
• Lack of SSL Pinning
• Automated scanning results such as sqlmap, Burp active scanner etc, that have not been manually verified

Thank you for helping keep Supabase and our users safe!