Is Supabase Encryption Strong Enough for Sensitive Data?

Decloak is an AI-powered web security intelligence platform that scans a site's HTTP/TLS posture, JavaScript, and third-party scripts to produce a report anyone can read. This guide is part of Decloak's library of practical, source-backed security guidance.

Key takeaways

• Supabase encrypts all database files, WAL logs and backups with AES - 256 automatically.
• All network traffic to Supabase services must use TLS 1.2 or higher; verify-full is the recommended sslmode.
• The Supabase Vault stores secrets using libsodium AEAD; keys live outside the database and are never exposed in SQL.
• To avoid leaking plaintext secrets, disable statement logging for tables that use Vault.
• Supabase’s encryption meets SOC 2 Type 2, HIPAA, ISO 27001 and GDPR requirements.

Does Supabase encrypt data at rest?

Yes, Supabase encrypts every piece of data on disk, including tables, indexes, WAL logs and daily backups, using AES - 256. The encryption is applied at the storage layer, is transparent to the developer and cannot be turned off.

The platform manages the encryption keys internally. When you create a project a per - project root key is generated and stored in Supabase’s secured backend services. This key is used for all at - rest encryption operations and is never written to the database itself.

How does Supabase protect data in transit?

All connections to Supabase services (PostgREST, Realtime, Storage, Auth) require TLS 1.2 or higher. The PostgreSQL client can be configured with any standard sslmode option; the strongest setting is verify-full, which validates both the server certificate authority and the hostname.

-- Example connection string with strict TLS verification
psql "postgresql://USER:PASS@db.supabase.co:5432/DBNAME?sslmode=verify-full"

Projects can also enable SSL enforcement in the dashboard, which forces all Postgres connections to use TLS and triggers a brief database reboot.

What is Supabase Vault and how does it encrypt secrets?

Supabase Vault is a built - in secret store that provides a table vault.secrets and a view vault.decrypted_secrets. Secrets are encrypted using Authenticated Encryption with Associated Data (AEAD) based on libsodium. The encryption keys are never stored in the database; only a key - identifier is persisted.

When you insert a secret:

INSERT INTO vault.secrets (name, secret) VALUES ('api_key', 'my - super - secret');

the value is encrypted client - side and written as bytea. Decryption happens only when you query the view:

SELECT * FROM vault.decrypted_secrets WHERE name = 'api_key';

The per - project root key lives in Supabase’s backend and can be fetched via the Management API (a 64 - character hex string) if external decryption is required.

Can I encrypt arbitrary columns with Supabase?

Yes. Vault’s Transparent Column Encryption (TCE) lets you encrypt any column in a user table. The encrypted value is stored as bytea or text and can be decrypted through the same view - based API. TCE uses the same libsodium - based AEAD as the secret store, so integrity and confidentiality are guaranteed.

How should I protect my secrets from accidental logging?

By default Supabase logs all SQL statements, which would expose plaintext secrets inserted into vault.secrets. To mitigate this risk, disable statement logging for projects that use Vault:

ALTER SYSTEM SET statement_log = 'none';
-- Then restart the project for the change to take effect

This ensures that INSERT and UPDATE statements containing raw secret values are not written to the logs.

Does Supabase meet compliance standards?

Supabase’s encryption controls satisfy major regulatory frameworks, including SOC 2 Type 2, HIPAA (with a Business Associate Agreement), ISO 27001 and GDPR. The combination of AES - 256 at rest, TLS 1.2+ in transit, and AEAD - based secret storage helps organizations meet data - protection requirements.

How does Supabase compare to a DIY encryption setup?

What steps should I take to harden Supabase encryption?

1. Enable SSL enforcement in the project settings to force TLS for every connection.
2. Use sslmode=verify-full in all client connection strings.
3. Store any sensitive configuration values in vault.secrets or encrypt columns with TCE.
4. Disable statement logging (ALTER SYSTEM SET statement_log = 'none';).
5. Rotate the root key only via the Management API if you suspect compromise.
6. Regularly review the compliance dashboard in the Supabase console to ensure controls remain active.

When might I need to retrieve the root key?

If you need to decrypt Vault data outside of Supabase - such as during a migration to another platform - you can fetch the 64 - character hex root key via the Management API. Store this key in a secure secret manager and never embed it in application code.

For teams that already use Decloak, the free scan will surface any publicly readable Supabase tables, misconfigured SSL settings, or missing Vault encryption, giving you an early warning before a breach.