Is Supabase GDPR compliant for European user data?

Supabase is GDPR-compliant when configured correctly. This means: selecting an EU region (Frankfurt or Ireland) for your project; signing the Data Processing Agreement (available in the Supabase dashboard on Pro plans); enabling Row-Level Security; and implementing the user-facing data rights (access, deletion, export) in your application. Supabase provides the infrastructure — you configure it appropriately for your use case.

What is Row-Level Security and why does it matter?

Row-Level Security (RLS) is a database feature that automatically filters query results based on the authenticated user's identity. Without RLS, every authenticated user can query every row in your database. With RLS, each user can only see and modify rows that match their policy — typically rows belonging to their organisation or user account. RLS is enforced at the database engine level, making it impossible to bypass from the application layer.

Do I need SOC 2 compliance for my SaaS?

You don't need SOC 2 certification to sell to SMEs, but you will need it to sell to enterprise customers. Most enterprise procurement teams require SOC 2 Type II from their SaaS vendors. When you build on Supabase, you can leverage Supabase's SOC 2 certification for the infrastructure layer. You'll still need to obtain SOC 2 certification for your application layer if enterprise sales is a significant goal — typically after Series A, with companies like Vanta or Drata to automate the process.

How do I handle the right to erasure (right to be forgotten) under GDPR?

Implement a data deletion endpoint in Xano that: deletes or anonymises the user's record in your users table; deletes or anonymises any personally identifiable information in related tables; removes the user from Supabase Auth (which deletes their email and auth credentials); and logs the deletion event in your audit log. Test this process with a real test account before launch. Keep audit logs even after deletion — they contain action records, not personal data.

Is it safe to use the Supabase anon key in my WeWeb frontend?

Yes — the anon key is designed to be public. It identifies your project to Supabase but has no special privileges. All access is controlled by your RLS policies. What is NOT safe to expose in the frontend is your service role key, which bypasses RLS entirely. Keep the service role key exclusively in server-side environments (Xano environment variables, Supabase Edge Functions secrets). Never put it in WeWeb or any client-side code.

No-Code Security and Compliance: GDPR, Row-Level Security, and SOC 2 with Supabase

Security and compliance are not optional features you add after launch. They're architectural decisions you make at the beginning — and getting them wrong in a no-code application is exactly as costly as getting them wrong in a custom-coded one. At App Studio, every production application we build goes through a security checklist before deployment. This article shares the complete picture: what the risks are, how Supabase's architecture addresses them, and the specific implementation patterns that keep our clients' applications GDPR-compliant and secure.

Why Security in No-Code Is Often Underestimated

There's a pervasive misconception that using managed services means security is someone else's problem. "Supabase handles security, right?" Sort of. Supabase provides the security mechanisms — encryption, RLS, audit capabilities — but you must configure and activate them correctly. A Supabase database with Row-Level Security disabled is as exposed as a database with no access controls at all.

We've reviewed dozens of no-code applications built by other agencies and freelancers, and the most common critical vulnerability is always the same: RLS disabled or incorrectly configured. In one case, we reviewed an application where any authenticated user could query any other user's records by simply calling the Supabase API with their own JWT. The frontend hid this by only querying the current user's data — but there was nothing preventing a technically literate user from calling the API directly.

This is the "security through obscurity" anti-pattern applied to no-code. The frontend is not a security layer. Any data accessible via the Supabase API is accessible to any authenticated user unless RLS policies explicitly prevent it. Understanding this principle is the foundation of everything that follows.

GDPR Fundamentals for SaaS Founders

GDPR (General Data Protection Regulation) applies to any company that processes personal data of EU residents — regardless of where the company itself is based. If your SaaS has EU users, GDPR applies to you. The consequences of non-compliance range from formal reprimands to fines of up to 4% of global annual turnover or €20 million, whichever is higher.

The five GDPR principles most relevant to SaaS: (1) Lawful basis — you need a legal basis to process each category of personal data (consent, contract necessity, or legitimate interest are the most common). (2) Data minimisation — only collect data you actually need. (3) Purpose limitation — don't use data for purposes other than those disclosed. (4) Storage limitation — don't keep personal data longer than necessary. (5) Rights of data subjects — users have the right to access their data, correct it, delete it, and export it.

For most B2B SaaS products, the practical GDPR requirements are: a Privacy Policy that accurately describes your data processing; a cookie consent mechanism; a data subject request process (deletion, export); a Data Processing Agreement with each of your processors (including Supabase); and appropriate technical security measures.

Where Data Lives in the WeWeb + Supabase Stack

Understanding your data topology is essential for GDPR compliance. In the WeWeb + Supabase stack, data at rest lives in Supabase's PostgreSQL database. For EU compliance, select the EU-Central-1 (Frankfurt) or EU-West-1 (Ireland) region when creating your Supabase project. This ensures personal data stays in the EU, satisfying the GDPR data residency requirement without relying on Standard Contractual Clauses for US data transfers.

Data in transit: all communication between WeWeb (running in the user's browser) and Supabase is encrypted via TLS 1.3. Supabase enforces HTTPS on all endpoints — there's no option to use unencrypted connections. Similarly, all WeWeb-to-Xano communication is TLS-encrypted.

Data in WeWeb: WeWeb itself doesn't persist user data. It's a frontend renderer that fetches data from Supabase, displays it, and discards it when the session ends. The exception: if you use WeWeb's local storage or session storage for caching, that data exists in the user's browser. Be deliberate about what you cache locally — don't cache sensitive personal data in browser storage.

Supabase's Compliance Posture

Supabase holds SOC 2 Type II certification — the most rigorous independent security certification for cloud infrastructure. Type II (as opposed to Type I) means the auditor observed Supabase's controls functioning over a 6-12 month period, not just reviewed a point-in-time snapshot. For enterprise clients, we provide Supabase's SOC 2 report under NDA to satisfy security review requirements.

ISO 27001 certification is additionally held by Supabase, covering information security management. For clients in regulated industries (financial services, healthcare, insurance), this is often required by their compliance framework.

Supabase's GDPR posture: Data Processing Agreement available and signed via the Supabase dashboard (Pro plan and above). Sub-processors list published at supabase.com/legal/dpa and updated with notice. EU data residency available on all paid plans. Right to erasure: Supabase provides tools to delete all data associated with a user, which your application can expose to users directly. Point-in-time recovery on Pro plans (7 days) and Enterprise plans (up to 90 days) satisfies recovery time objective requirements for most enterprise risk frameworks.

Row-Level Security: The Foundation of Multi-Tenant Data Safety

Row-Level Security (RLS) is a PostgreSQL feature that Supabase exposes as first-class functionality. When RLS is enabled on a table, every query is automatically filtered by the active policy — even if the application sends a query that doesn't include a WHERE clause. RLS operates at the database engine level, below the application layer.

The essential multi-tenant RLS pattern: every row in a user-data table has an `organisation_id` column. Your RLS SELECT policy reads: `auth.jwt() ->> 'organisation_id' = organisation_id::text` — meaning the authenticated user can only SELECT rows where the row's organisation_id matches the organisation_id embedded in their JWT.

This policy must be set separately for SELECT, INSERT, UPDATE, and DELETE. A common mistake is setting SELECT-only RLS and forgetting UPDATE, leaving users unable to read other organisations' data but able to overwrite it. Test all four operations with two test accounts from different organisations before launch.

For role-based filtering within an organisation (e.g., managers see all records, employees see only their own), add a second condition to the policy using the user's role claim from the JWT. This keeps all access control logic at the database level, where it cannot be bypassed.

Implementing RBAC in Supabase and WeWeb

Role-Based Access Control at the data layer is implemented via RLS policies parameterised by role. At the application layer (WeWeb), RBAC controls UI visibility — which menu items, buttons, and pages a user sees. Both layers are necessary: RLS is your security guarantee, WeWeb RBAC is your UX.

The implementation pattern we use: store the user's role in the `users` table (e.g., `role: "admin" | "manager" | "viewer"`). When the user authenticates, Supabase returns their profile including role. WeWeb reads this role into a global user state object. Conditional visibility rules on WeWeb components reference this state: the "Delete" button is only visible if `user.role === "admin"`.

Critically, the WeWeb visibility rule is not your security control — it's your UX control. The security control is the RLS policy that rejects DELETE operations from non-admin users at the database level. Both layers working together means: admin users see the delete button and can use it; non-admin users don't see the button, and even if they construct a direct API call, the database rejects it.

Audit Logging Patterns for Compliance

Audit logs are required for SOC 2 compliance, strongly recommended for GDPR incident response, and often required in regulated industries. A proper audit log records: who performed an action, what action they performed, when they performed it, and what changed (before and after state for updates).

In Supabase, implement audit logging via PostgreSQL triggers. Create an `audit_log` table with columns: `id`, `table_name`, `record_id`, `action` (INSERT/UPDATE/DELETE), `old_data` (JSONB), `new_data` (JSONB), `user_id`, `created_at`. Write a trigger function that populates this table on any INSERT, UPDATE, or DELETE to your important tables.

For Xano-mediated operations, log at the Xano level as well — Xano's API call log provides the request payload, response, authenticated user, and timestamp. Combined, the Supabase trigger logs and Xano API logs give you a complete audit trail.

Audit log retention: keep audit logs for a minimum of 12 months for GDPR incident response purposes. Many regulated industries require 3-7 years. Supabase's storage costs for audit logs are minimal — a year of audit data for a 1,000-MAU product typically consumes less than 1GB.

Encryption at Rest and in Transit

Supabase encrypts all data at rest using AES-256, the industry standard. This encryption is handled at the infrastructure level by AWS (where Supabase runs) — it's automatic and requires no configuration from you. All backups are also encrypted.

For sensitive fields that require column-level encryption (e.g., personal identification numbers, financial account details, health information), Supabase integrates with pgcrypto, PostgreSQL's built-in cryptography extension. Column-level encryption means even a database administrator cannot read the encrypted value without the decryption key. We implement this for any field classified as "special category data" under GDPR (health, financial, biometric).

All data in transit is protected by TLS 1.3. Supabase rejects connections using TLS 1.0 or 1.1. Certificate pinning is available for mobile applications built with FlutterFlow. For WeWeb applications, the browser's standard TLS implementation handles this — modern browsers only connect via TLS 1.2 or higher by default.

One frequently overlooked vector: database connection strings. Never expose your Supabase connection string (for direct PostgreSQL connections) in client-side code. The service role key (which bypasses RLS) must only exist in server-side environments (Xano, Edge Functions, CI/CD secrets). The anon key (used in WeWeb) is safe to expose because RLS policies restrict what it can access.

Security Checklist Before Launch

Run through this checklist before launching any production application.

**Database**: RLS enabled on every table containing user data; policies tested for SELECT, INSERT, UPDATE, and DELETE with two separate test organisations; service role key not present in any client-side code; all foreign key relationships enforced with ON DELETE behaviour defined.

**Authentication**: email confirmation required for new accounts; password minimum length set to 8+ characters; rate limiting enabled on auth endpoints (Supabase Auth includes this by default); OAuth redirect URLs whitelisted to your production domains only.

**API security**: all Xano endpoints require authentication (no public write endpoints); input validation on all user-supplied fields; SQL injection impossible (Supabase's parameterised queries handle this, but verify any raw SQL in Edge Functions); API rate limiting configured.

**Compliance**: Privacy Policy reviewed by a legal professional; cookie consent configured; DPA signed with Supabase; data deletion endpoint tested end-to-end; audit logging active on sensitive tables; EU data residency region confirmed in Supabase project settings.

**Operational**: Sentry or equivalent error monitoring configured; database backup verified (restore test, not just backup confirmation); uptime monitoring on production domain; incident response contact defined.