Over the past 3 months, the team has been focused on security, performance, and stability. This is always part of our mandate, but for this period we have been exclusively focused on this task.
And we haven't been alone with security. @xyzeva (Eva), a rising star in the world of security, has been instrumental in the past 3 months - everything from discovering misconfigured projects to collaborating on fixes and features.
This post outlines the key initiatives that we have collaborated on and a few more in the pipeline.
Learning from our peers
Eva and her colleagues are the authors of Firewreck, which exposed the misconfiguration of Firebase instances. This HN comment highlights the key challenges for Firebase (paraphrased):
.. First, security rules as implemented by Firebase are still a novel concept.
.. Second, without the security of obscurity created by random in-house implementations of backends, scanning en masse becomes easier.
.. Finally, security rules are just hard.
And then an important technical distinction:
Technically there is nothing wrong with the Firebase approach but ... it opens itself up to misunderstanding, improper use, and issues like this.
Supabase's approach
Security is a Shared Responsibility Model. The more control you are given with a technology, the more opportunity you have to make a mistake.
We believe that we can give developers full control of their tools, while also being the most secure platform to develop with. How?
- By providing security tooling, baked deeply into our platform.
- By leaning into existing standards like Postgres Row Level Security (RLS), instead of using custom systems.
Security tools and guides
This post consolidates the tools and guides that we have available for the community.
Lunchcat
Eva has added support for Supabase in Lunchcat, the AI-Powered security company she works for. Parts of this tooling is available for self-hosting today, and will be available as an integration once their platform is publicly available.
Security Advisor
We launched our Security Advisor in the last Launch Week. Eva was a big contributor to this, helping to set up a robust set of security rules. These rules are available in the Dashboard, many with one-click solutions.
Security emails and notifications
The security rules in our Security Advisor are run against all of your projects and project owners now receive weekly emails with a list of security issues that need to be solved. Since all of the advisories are open source, you can also use them inside your CI/CD pipeline.
Disabling the default Data API
We have made it even easier to turn off the Data API if you don’t plan to use it. When you launch a project you can choose whether you want to create it with only Postgres connections, or if you also want the Data API. You can also turn off the Data API at any time in your project settings.
API hardening
We have made it simple to switch the default schema from public to api in the API Settings page. We have also released a guide for Hardening the Data API, outlining various approaches for using the Data API. It’s very likely that we will make this the default set up in the future to align with PostgREST’s Schema Isolation guide.
Column level security
We’ve added guides and a simple-to-use dashboard for column-level grants. This allows you to manage Postgres grants for every role (including the default Supabase anon and service_role). Combining this with RLS gives you extremely fine-grained control of your database.
User impersonation
We have added User/Role impersonation to the Dashboard. You can use this to switch between anonymous and authenticated roles, or even go as deep as selecting an individual user (if you use Supabase Auth) to see the level of data that they use.
RLS AI Assistant
RLS policies are even easier with our new GPT-4o powered AI Assistant. We want Row Level Security to be easier than any other security tool on the market. We have added a ton of tests to ensure that we have the most accurate Postgres RLS assistant available, for free.
Network Restrictions
You can restrict access to your database at the network level for any direct access to your database. This is especially useful when you’re getting started and only want to give direct access to your own IP address.
And more
Our docs are full of best practices and useful info:
Misconceptions and bad practices
Since we see a few common complaints about Row Level Security, we figured we would address them.
-
“It’s unsafe to communicate from the browser directly to the database.”
The Database-centric approach is a three-tier architecture, the same as any other tool like NodeJs, Django, or RoR. The key difference is that you write your security rules in the SQL. It is also a different “workflow” from a three-tier approach, where traditionally you write authorization rules as part of your middleware rather than when you are setting up your database.
Supabase is agnostic which approach you take. If SQL makes you uncomfortable, you can use the Postgres server we provide just like any other Postgres service.
-
“I turned off RLS while prototyping.”
By default, Supabase enables RLS for all tables created via the dashboard. Some developers disable this while they are prototyping which is not recommended. The best way to solve this is to use our CLI for Local Development. The CLI provides the entire Supabase stack, directly on your local development machine.
-
"I forgot to enable RLS."
Our dashboard has copious warnings when you have disabled RLS for any table. We also surface this in the Security Advisor, warnings via email and dashboard notifications.
That said, there are some legitimate difficulties with RLS - it’s not a silver bullet by any means. We are planning a lot more tooling to make this easier for Postgres and Supabase developers.
Future developments
This is just the beginning of our tooling efforts, with many more ideas in the pipeline. We have hired dedicated security engineers to continue working on these initiatives, including:
-
Improved Security Advisor
As we continue to discover misconfigurations and potential vulnerabilities we will continue to improve the suite of security rules that we enable across our entire fleet of database.
-
Network restrictions 2.0
Networking should be as easy as using the database in Supabase. We’ve got a tonne of plans for this: network peering, Tailscale integration, better API Key management, fine-grained restrictions for each service and project scoped roles.
-
OpenAPI management
We will be giving developers the ability to control the visibility of the OpenAPI spec based on the Postgres roles and grants. This provides some level of security through obscurity.
-
Development on "Hard mode"
Not all projects are alike. While some require extremely strict levels of access, others can be a bit more relaxed. This is explained in our Maturity Models framework. We are brainstorming ways to codify this, so that developers can “turn up” the enforced security levels on their projects, restricting what developers can and cannot do.
-
CI/CD warnings
We will be adding the Security Advisories into our CLI for first-class support within GitHub Actions and CI/CD pipelines. Combined with Branching, this prevents security misconfigurations before they ever reach production.
-
Revamped API keys
Soon we will be replacing the
anonandservice_roleAPI keys with a simplerpublicandadminkey. This new setup will be conceptually similar, but will allow developers to create more fine-grained authorization rules and allow them to roll individual keys in case of a leak.
Supabase Responsible Disclosure Program
Eva approached us during our last Launch Week. While she was helping us with the Security Advisor she discovered a misconfiguration in one of our own applications using Supabase with Lunchcat. We were able to solve this quickly by toggling off read access to the anon role and scanning the access logs to ensure no malicious actors had accessed the data.
At the time, we didn’t have the Security Advisor to help the developer discover the misconfiguration before publishing. The Supabase Security suite is being developed to prevent this ever occurring again - for us and for our customers.
But no platform is infallible: when tooling doesn’t work, we rely on our community to help discover and responsibly disclose any vulnerabilities. We are launching a private Vulnerability Disclosure Program today with HackerOne. We commit to transitioning to a public disclosure program in a month, once we iron out the initial kinks. If you cannot wait till then, use our secret link submit a report.
If you find any misconfigured projects, please let us know. We will work with those customers to ensure that they know about the issue and can solve it. If you are a security professional, we welcome your help to secure the Supabase community.