--- title: "Is Supabase secure? What it covers and what you must" description: "Supabase is SOC 2 Type 2 and ISO 27001 certified, with encryption at rest and in transit. Whether your data is safe depends on settings only you control." url: "https://madsalt.tech/blog/is-supabase-secure/" author: "Denys Zaichenko" language: "en" published: 2026-10-26 --- # Is Supabase secure? What it covers and what you must TL;DR Yes, the platform is secure: Supabase is SOC 2 Type 2 and ISO 27001 certified, encrypts data at rest with AES-256 and in transit with TLS, and signs HIPAA agreements on the Team plan and above. Your project is a different question. Under Supabase's shared responsibility model, access to tables, API keys and auth settings are yours, and the platform does exactly what those settings say. On my local test table, one setting decided whether a public key got 0 rows or all 3. I'm Denys, a full-stack and AI engineer, and most apps I build or fix run on Supabase. Clients ask "is Supabase secure?" when they mean "is my data safe?". Those have different answers, so this article takes them one at a time. ## Is the Supabase platform secure? The platform side is audited by third parties. From Supabase's [security page](https://supabase.com/security) and [security docs](https://supabase.com/docs/guides/security), read on 23 October 2026: | Control | What Supabase states | | -------------- | --------------------------------------------------------------------------------------------------- | | SOC 2 Type 2 | Audited yearly; the report is available to Team and Enterprise customers | | ISO 27001 | Certified; the certificate is available to Team and Enterprise customers | | HIPAA | Supported with a signed Business Associate Agreement and the HIPAA add-on, Team plan and above | | Encryption | AES-256 at rest, TLS in transit; access tokens and keys are also encrypted at the application level | | Backups | Daily for paid projects; Point in Time Recovery as an add-on from the Pro plan | | Data residency | Database, Auth and Storage stay in the AWS region you pick | None of this protects a table you left open. The [SOC 2 guide](https://supabase.com/docs/guides/security/soc-2-compliance) says it plainly: Supabase's compliance does not transfer to anything outside its control. ## What is your part? Supabase's [shared responsibility model](https://supabase.com/docs/guides/deployment/shared-responsibility-model) lists what is always yours: your account, access management for the database and its tables, your data, and applying security controls, including the warnings Security Advisor raises. In practice that means four layers of settings: ![Who guards each step of a request. Supabase runs the transport and the keys; grants and policies are yours. From a browser: Browser → TLS, key · Supabase → Grant · you → RLS · you; From your server: Server → TLS · Supabase → Secret key · you → RLS skipped.](https://madsalt.tech/charts/en/is-supabase-secure.svg) *Figure 1. Based on Supabase's shared responsibility model and API keys guide, October 2026.* 1. **Who can touch a table.** Grants decide whether `anon` and `authenticated` reach a table at all. RLS policies decide which rows. 2. **Which key goes where.** The publishable key is public by design, the secret key bypasses RLS. I compared them in [Supabase anon key vs service role key](https://madsalt.tech/blog/supabase-anon-key-vs-service-role-key/). 3. **Auth settings.** Email confirmation, leaked password protection (Pro plan and above), minimum password length, MFA, redirect URLs, CAPTCHA. 4. **Everything around the database.** Storage buckets and their policies, `SECURITY DEFINER` functions, Edge Functions that use the secret key, and which schemas the Data API exposes. ## How much does one setting change? I ran the same request against one table of three fake orders on a local Supabase stack (CLI 2.109.1, Postgres 17.6, PostgREST 14.14), with the publishable key, as a browser would: | Setting on the table | What the public key got | | ----------------------------- | ------------------------------------------------ | | RLS off | All 3 rows, and an insert returned `201 Created` | | RLS on, no policy | `[]` | | RLS on, policy `using (true)` | All 3 rows | | No grant for `anon` | `42501 permission denied` | Same platform, same encryption, same certifications. The difference is a line of SQL. This is why a "secure platform" and a leaking app are not a contradiction: [CVE-2025-48757](https://mattpalmer.io/posts/2025/05/statement-on-CVE-2025-48757/) found 170 of 1,645 Lovable showcase apps serving data to the public key, all on the same audited platform. ## Is Supabase getting safer by default? Yes, in steps. Supabase's [changelog of 28 April 2026](https://supabase.com/changelog/45329-breaking-change-tables-not-exposed-to-data-and-graphql-api-automatically) lists an RLS-on-by-default toggle, a Data API exposure badge, granular per-table grants and a restriction on schema enumeration. The biggest one lands on 30 October 2026: new tables in existing projects stop getting Data API grants automatically, so a forgotten table returns `42501` instead of its rows. Existing tables keep their grants, so this does not fix anything already open. The legacy `anon` and `service_role` keys are also being deprecated by the end of 2026 in favour of publishable and secret keys; the new secret key refuses requests from a browser. What else the switch breaks, and four checks to run before it: [Supabase October 30 grant change: what breaks, how to check](https://madsalt.tech/blog/supabase-october-30-grant-change/). ## How do you check your own project? Start with Supabase's own Security Advisor and fix every warning. Then check what it does not cover: - Run the free [Supabase security check](https://madsalt.tech/tools/supabase-security-check/). It connects read-only and grades the project against 46 rules mapped to OWASP Top 10:2025: RLS, policies, views, functions, grants, storage and auth settings, with fix SQL for each finding. - Test with two users in two companies. No scanner knows which rows belong to whom; the test is in my [Lovable app security checklist](https://madsalt.tech/blog/lovable-app-security-checklist/). - If your app has roles and a permission screen, prove each permission box does what it says, as in [how to test Supabase RLS](https://madsalt.tech/blog/how-to-test-supabase-rls/). So: Supabase is a secure place to keep data, and it gives you the tools to keep it private. Whether it stays private is decided in your schema and your settings. Weighing Supabase for a project? Happy to compare notes on what to set up first. No pitch. [Get in touch](https://madsalt.tech/#contact)