Public Table Exposure

Qué significa “Public Table Exposure” (explicación simple)

Public Table Exposure . Builders use this concept to reduce accidental exposure and keep sensitive operations behind clear authorization boundaries.

En resumen: si alguien puede acceder al recurso directamente (sin pasar por tu backend), el control real está en la base/Storage/RPC — no en tu UI.

Explicación técnica: cómo funciona Public Table Exposure en Supabase

En Supabase, PostgREST expone endpoints REST para tus tablas. Si una tabla tiene grants amplios o RLS no está configurado correctamente, una persona puede consultar la tabla directamente sin pasar por tu aplicación. El patrón típico es “la UI no muestra nada”, pero la API sí entrega filas. Para la mayoría de apps con datos sensibles, la postura más segura es backend-only: el navegador no consulta tablas directamente.

Rutas de ataque y fallos comunes (Public Table Exposure)

• SELECT/INSERT/UPDATE/DELETE permitidos a anon/authenticated en tablas sensibles.
• RLS desactivado: políticas no se ejecutan.
• Vistas o funciones que exponen columnas sensibles indirectamente.
• IDs enumerables: seguridad basada en “no adivinar” falla.
• Acceso directo vía REST aunque la UI esté “bloqueada”.

Dónde mirar en tu proyecto (Supabase)

• Grants por rol en tablas/vistas (especialmente en user/billing/admin).
• RLS activado/forzado en tablas con datos personales.
• Código del cliente que llama a /rest/v1 directamente.
• RPC o vistas que devuelven los mismos datos por otro camino.

Cómo suele fallar Public Table Exposure en Supabase

Estos son patrones que aparecen una y otra vez en proyectos reales:

• Assuming authentication alone is sufficient and granting the authenticated role full table access.
• Believing hidden UI components mean the table is private while the DB remains accessible.
• Running large SELECTs or writes directly from client code for convenience instead of routing through backend checks.

Cómo detectar problemas de Public Table Exposure

El objetivo es comprobar el comportamiento real, no lo que “parece” en la UI.

• Prueba un GET directo a la tabla (con anon/auth) y revisa si devuelve filas.
• Busca tablas con RLS desactivado o con políticas demasiado amplias.
• Audita grants a roles de cliente en esquemas y tablas sensibles.
• Comprueba si columnas sensibles se filtran solo en la UI.
• Repite el test en prod (no solo en dev).

Cómo corregir Public Table Exposure (enfoque backend-only)

1. Implementa endpoints backend para lecturas/escrituras necesarias con autorización.
2. Revoca grants a roles de cliente sobre tablas sensibles.
3. Activa y fuerza RLS donde aplique como defensa adicional.
4. Reduce superficie: evita exponer tablas completas si solo necesitas vistas seguras.
5. Verifica con llamadas directas: el acceso debe fallar.
6. Añade un guardrail para detectar grants nuevos tras migraciones.

Checklist de verificación (después de corregir)

1. El GET directo ya no devuelve filas (401/403 o conjunto vacío por políticas estrictas).
2. El backend devuelve solo los campos permitidos para el usuario actual.
3. No hay rutas alternativas (vistas/RPC) que vuelvan a exponer la tabla.
4. Re-escaneo confirma que la tabla ya no es accesible desde el cliente.
5. Checklist en releases captura cambios futuros.

Prevención de drift (para que no vuelva)

• Mantén una lista explícita de recursos que el cliente puede leer (idealmente: ninguno sensible).
• Revisa grants en cada migración y antes de lanzamientos grandes.
• Estandariza una arquitectura backend-only para recursos sensibles.

Ejemplos y por qué funcionan

Estos ejemplos muestran escenarios concretos, causa raíz y corrección:

• Public read on profiles table → /examples/public-table-exposure/public-read-on-profiles — A public profiles table accepted authenticated SELECTs so anyone could scrape user info.
• Public write on invitations enables abuse → /examples/public-table-exposure/public-write-on-invitations — Allowing authenticated users to insert into the invitations table invited attackers to spam invites and rack up costs.

Úsalos para reconocer el patrón en tu propio esquema y repetir la verificación.

Enlaces relacionados (English canonical + templates)

• English canonical: Public Table Exposure → /glossary/public-table-exposure
• Template: Lock down a public table (backend-only access) → /templates/access-control/lock-down-public-table

Preguntas rápidas (auto‑evaluación)

Si respondes “sí” a cualquiera de estas preguntas, vale la pena priorizar este fix:

• ¿Puedo acceder al recurso con una llamada directa (sin pasar por mi backend)?
• ¿El control de acceso depende de la UI (botones/ocultar pantallas) en lugar de la base/Storage?
• ¿No tengo una verificación repetible que pueda ejecutar tras migraciones?
• ¿Hay diferencias entre dev/staging/prod que podrían reintroducir exposición (drift)?
• ¿Estoy usando políticas/grants amplios por “comodidad” y sin documentación?

El objetivo no es “hacerlo perfecto”; es reducir exposición con un cambio pequeño, verificable y repetible.

Notas culturales/idioma

Esta página está optimizada para consultas en తెలుగు. Si necesitas máxima precisión técnica, usa también la página en inglés (canonical).

Resumen rápido (para llevar)

• Valida siempre con acceso directo: los atacantes no usan tu UI.
• Prefiere backend-only para recursos sensibles y usa verificación repetible.
• Después de cada migración, re-ejecuta checks para evitar drift.
• Mantén secretos server-only y revisa grants/políticas/buckets/EXECUTE con disciplina.

Plantilla de “enunciado de límite” (para documentar el fix)

Este enunciado te ayuda a dejar claro el modelo de acceso y a detectar regresiones:

• Solo el backend puede (operación) sobre (recurso) tras autorización explícita.
• El cliente no debe poder acceder directamente a (tabla/bucket/función) con credenciales anon/auth.
• Verificación: la llamada directa (describe la petición) debe fallar en dev/staging/prod.

Guardar este enunciado junto con la evidencia (antes/después) hace que revisiones y migraciones sean más seguras.

Mini ejemplo de verificación (sin SQL)

Si quieres una verificación rápida sin meterte en SQL, usa este enfoque:

1. Antes del fix, intenta una llamada directa desde el cliente (REST/RPC/Storage) y guarda el resultado.
2. Aplica el cambio (backend-only + revocar accesos amplios) y repite la misma llamada directa.
3. Confirma que ahora falla con una denegación clara, y que el backend autorizado sigue funcionando.
4. Repite en staging/prod para evitar el clásico “funciona en dev”.

Si estas cuatro líneas se cumplen, tu corrección es real y resistente a regresiones.

Plan operativo de 7 días (aplícalo sin bloquear producto)

Este plan está pensado para equipos pequeños que necesitan mejorar seguridad sin frenar entregas. La idea es hacer un cambio corto, verificable y repetible cada día, con foco en evidencia y no en teoría.

1. Día 1: identifica el recurso más sensible relacionado con este término y reproduce el riesgo con una llamada directa.
2. Día 2: crea o ajusta la ruta backend-only y documenta la regla de autorización en una frase.
3. Día 3: revoca el acceso directo amplio desde cliente (grants, bucket público o EXECUTE público, según aplique).
4. Día 4: ejecuta verificación en dev y staging con la misma prueba directa; debe fallar de forma consistente.
5. Día 5: repite en producción y guarda evidencia mínima (qué cambió, prueba usada, resultado esperado).
6. Día 6: añade guardrail post-migración (scan o checklist) para evitar drift silencioso.
7. Día 7: revisa una ruta relacionada (tabla, Storage o RPC) y repite el ciclo con menor fricción.

Si mantienes este ritmo semanal, reduces exposición real sin depender de “arreglos heroicos” de último minuto.

Siguiente paso

Si sospechas exposición en tu proyecto, ejecuta un escaneo y valida el acceso directo. Después aplica un template y verifica que el acceso desde el cliente ya no funcione.