--- title: "¿Es seguro Supabase? Qué cubre y qué le toca a usted" description: "Supabase tiene SOC 2 Type 2 e ISO 27001, con cifrado en reposo y en tránsito. Que sus datos estén a salvo depende de ajustes que solo usted controla." url: "https://madsalt.tech/es/blog/is-supabase-secure/" author: "Denys Zaichenko" language: "es" published: 2026-10-26 --- # ¿Es seguro Supabase? Qué cubre y qué le toca a usted En resumen Sí, la plataforma es segura: Supabase tiene SOC 2 Type 2 e ISO 27001, cifra los datos en reposo con AES-256 y en tránsito con TLS, y firma acuerdos HIPAA en el plan Team y superiores. Su proyecto es otra pregunta. Con el modelo de responsabilidad compartida de Supabase, el acceso a las tablas, las API keys y los ajustes de auth son suyos, y la plataforma hace exactamente lo que esos ajustes dicen. En mi tabla de prueba local, un solo ajuste decidió si una clave pública obtenía 0 filas o las 3. Soy Denys, ingeniero full-stack y de IA, y la mayoría de las apps que construyo o arreglo corren sobre Supabase. Los clientes preguntan "¿es seguro Supabase?" cuando quieren decir "¿están seguros mis datos?". Son preguntas con respuestas distintas, así que este artículo las toma una por una. ## ¿Es segura la plataforma de Supabase? El lado de la plataforma lo auditan terceros. Según la [página de seguridad](https://supabase.com/security) y la [documentación de seguridad](https://supabase.com/docs/guides/security) de Supabase, leídas el 23 de octubre de 2026: | Control | Lo que declara Supabase | | ------------------- | ------------------------------------------------------------------------------------------------------------- | | SOC 2 Type 2 | Auditado cada año; el informe está disponible para clientes Team y Enterprise | | ISO 27001 | Certificado; el certificado está disponible para clientes Team y Enterprise | | HIPAA | Compatible con un Business Associate Agreement firmado y el complemento HIPAA, plan Team y superiores | | Cifrado | AES-256 en reposo, TLS en tránsito; los tokens de acceso y las claves también se cifran a nivel de aplicación | | Copias de seguridad | Diarias en los proyectos de pago; Point in Time Recovery como complemento desde el plan Pro | | Residencia de datos | La base de datos, Auth y Storage permanecen en la región de AWS que usted elija | Nada de esto protege una tabla que dejó abierta. La [guía de SOC 2](https://supabase.com/docs/guides/security/soc-2-compliance) lo dice claro: el cumplimiento de Supabase no se transfiere a nada que quede fuera de su control. ## ¿Qué le toca a usted? El [modelo de responsabilidad compartida](https://supabase.com/docs/guides/deployment/shared-responsibility-model) de Supabase enumera lo que siempre es suyo: su cuenta, la gestión de acceso a la base de datos y sus tablas, sus datos y la aplicación de los controles de seguridad, incluidos los avisos que lanza Security Advisor. En la práctica son cuatro capas de ajustes: ![Quién protege cada paso de una petición. Supabase cubre el transporte y las claves; los grants y las políticas son suyos. Desde un navegador: Navegador → TLS, clave · Supabase → Grant · usted → RLS · usted; Desde su servidor: Servidor → TLS · Supabase → Secret key · usted → RLS omitido.](https://madsalt.tech/charts/es/is-supabase-secure.svg) *Figura 1. Basado en el modelo de responsabilidad compartida de Supabase y su guía de API keys, octubre de 2026.* 1. **Quién puede tocar una tabla.** Los grants deciden si `anon` y `authenticated` llegan siquiera a una tabla. Las políticas RLS deciden qué filas. 2. **Qué clave va dónde.** La publishable key es pública por diseño, la secret key se salta RLS. Las comparé en [Supabase anon key vs service role key](https://madsalt.tech/es/blog/supabase-anon-key-vs-service-role-key/). 3. **Ajustes de auth.** Confirmación de correo, leaked password protection (plan Pro y superiores), longitud mínima de contraseña, MFA, redirect URLs, CAPTCHA. 4. **Todo lo que rodea a la base de datos.** Los buckets de Storage y sus políticas, las funciones `SECURITY DEFINER`, las Edge Functions que usan la secret key y qué esquemas expone la Data API. ## ¿Cuánto cambia un solo ajuste? Ejecuté la misma petición contra una tabla de tres pedidos falsos en un stack local de Supabase (CLI 2.109.1, Postgres 17.6, PostgREST 14.14), con la publishable key, como lo haría un navegador: | Ajuste de la tabla | Qué obtuvo la clave pública | | ------------------------------------- | ----------------------------------------------- | | RLS desactivado | Las 3 filas, y un insert devolvió `201 Created` | | RLS activado, sin política | `[]` | | RLS activado, política `using (true)` | Las 3 filas | | Sin grant para `anon` | `42501 permission denied` | Misma plataforma, mismo cifrado, mismas certificaciones. La diferencia es una línea de SQL. Por eso una "plataforma segura" y una app que filtra datos no se contradicen: [CVE-2025-48757](https://mattpalmer.io/posts/2025/05/statement-on-CVE-2025-48757/) halló 170 de 1.645 apps de muestra de Lovable que entregaban datos a la clave pública, todas sobre la misma plataforma auditada. ## ¿Es Supabase más seguro por defecto con el tiempo? Sí, por pasos. El [changelog de Supabase del 28 de abril de 2026](https://supabase.com/changelog/45329-breaking-change-tables-not-exposed-to-data-and-graphql-api-automatically) enumera un interruptor para tener RLS activado por defecto, una insignia de exposición de la Data API, grants granulares por tabla y una restricción a la enumeración de esquemas. El mayor llega el 30 de octubre de 2026: las tablas nuevas de los proyectos existentes dejan de recibir grants de la Data API automáticamente, así que una tabla olvidada devuelve `42501` en lugar de sus filas. Las tablas existentes conservan sus grants, así que esto no arregla nada que ya esté abierto. Las claves antiguas `anon` y `service_role` también se darán por obsoletas a finales de 2026 a favor de las publishable y secret keys; la nueva secret key rechaza las peticiones desde un navegador. Qué más rompe el cambio y cómo revisar el proyecto antes: [Supabase, 30 de octubre: qué rompe el cambio de grants](https://madsalt.tech/es/blog/supabase-october-30-grant-change/). ## ¿Cómo se comprueba su propio proyecto? Empiece por el Security Advisor de Supabase y corrija cada aviso. Después revise lo que no cubre: - Ejecute la [Auditoría de seguridad de Supabase](https://madsalt.tech/es/tools/supabase-security-check/) gratuita. Se conecta en solo lectura y califica el proyecto con 46 reglas alineadas con OWASP Top 10:2025: RLS, políticas, vistas, funciones, grants, storage y ajustes de auth, con el SQL de corrección de cada hallazgo. - Pruebe con dos usuarios de dos empresas. Ningún escáner sabe qué filas son de quién; la prueba está en mi [lista de seguridad para apps Lovable](https://madsalt.tech/es/blog/lovable-app-security-checklist/). - Si su app tiene roles y una pantalla de permisos, demuestre que cada casilla de permiso hace lo que dice, como en [cómo probar Supabase RLS](https://madsalt.tech/es/blog/how-to-test-supabase-rls/). Así que: Supabase es un lugar seguro para guardar datos, y le da las herramientas para mantenerlos privados. Que sigan siéndolo lo deciden su esquema y sus ajustes. ¿Está valorando Supabase para un proyecto? Me gustaría comparar notas sobre qué configurar primero. Sin pitch. [Escríbame](https://madsalt.tech/es/#contact)