Respuesta Rápida:
Row-Level Security (RLS) es la regla, dentro de tu base de datos, que asegura que cada usuario vea únicamente sus propios registros. Sin RLS, un solo error en el código puede exponer la información de todos tus clientes. Es la capa que separa un sitio profesional de un sitio que está a un bug de una filtración masiva.
Puntos Clave:
Si tienes un sitio web que captura correos electrónicos, procesa pedidos, gestiona cuentas de clientes o almacena cualquier dato personal, ya operas un sistema con responsabilidad legal y reputacional. Da igual si tu negocio está en Houston, Cypress, Monterrey o Bogotá: las reglas que protegen los datos de tus clientes son las mismas, y las consecuencias de no aplicarlas también.
Este artículo traduce los términos técnicos a lo único que importa para un dueño de negocio: qué preguntar, qué exigir y cómo identificar cuándo tu proveedor de tecnología te está exponiendo a un problema serio.
Row-Level Security, o seguridad a nivel de fila, es una característica de las bases de datos modernas que decide qué filas puede leer cada usuario. Es una regla aplicada dentro del motor de la base, no en el código de la aplicación. Esa distinción es lo que la hace tan poderosa.
Según la documentación oficial de Supabase, las políticas RLS funcionan como si se agregara automáticamente una cláusula WHERE a cada consulta. Un ejemplo típico se ve así: "El usuario solo puede ver su propio perfil", con una política que filtra por el ID del usuario autenticado. Si un programador olvida poner ese filtro en una consulta, RLS lo aplica de todos modos. Es una red de seguridad que actúa en el último nivel, antes de que cualquier dato salga de la base.
La misma documentación describe este patrón como defense in depth, defensa en profundidad: aunque otro control falle, RLS sigue ahí. Y subraya que, una vez activado RLS sobre una tabla, ningún dato es accesible a través de la API hasta que se creen políticas explícitas. Es decir: por defecto, todo está cerrado. La filosofía es la opuesta a la habitual en sitios pequeños, donde por defecto todo está abierto y la seguridad se "agrega después" (casi siempre, demasiado tarde).
Lo que pasa sin RLS:
Cualquier error en el código de la aplicación (un filtro mal escrito, un parámetro de URL que no se valida, un endpoint sin autenticación) deja la base de datos completamente expuesta. El cliente A puede leer la información del cliente B con solo cambiar un número en una URL. Esto no es teórico, es la mecánica real detrás de la mayoría de las filtraciones que terminan en titulares.
OWASP (Open Worldwide Application Security Project) describe su Top 10 como "un documento estándar de concientización para desarrolladores y seguridad de aplicaciones web". Es la lista de referencia, actualizada periódicamente, de los riesgos más críticos para aplicaciones web. La versión actual es OWASP Top 10 2025.
Para un dueño de negocio no hace falta memorizar la lista. Pero sí hace falta saber que existe, y hacer una pregunta sencilla a quien construye o mantiene tu sitio: "¿Cómo abordas los riesgos de OWASP Top 10?". La respuesta debe ser concreta. Si el proveedor no reconoce el nombre, ya tienes la respuesta más importante: tu sitio no se está construyendo con un marco de seguridad reconocido a nivel global.
Las categorías recurrentes en cada edición de OWASP Top 10 incluyen el control de acceso roto, las fallas criptográficas y las vulnerabilidades de inyección. RLS es precisamente uno de los controles que mitiga el riesgo número uno: control de acceso roto. Por eso vale la pena que tu equipo lo conozca por nombre.
Cifrado significa transformar los datos para que solo quien tiene la llave correcta pueda leerlos. Hay tres lugares donde tu sitio necesita cifrado real, no cosmético:
GDPR (Reglamento General de Protección de Datos) es, según GDPR.eu, "la ley de privacidad y seguridad más estricta del mundo". Entró en vigor el 25 de mayo de 2018. La parte que sorprende a la mayoría de los dueños de negocio en Estados Unidos y América Latina es su alcance:
"Si procesas los datos personales de ciudadanos o residentes de la UE, o ofreces bienes o servicios a tales personas, entonces el GDPR aplica para ti incluso si no estás en la UE."
— GDPR.eu
Las multas máximas, según el mismo texto, llegan a 20 millones de euros o el 4% de la facturación anual global, lo que sea mayor. Para un negocio pequeño esto puede sonar lejano, pero el principio importa: los datos personales tienen reglas, y esas reglas tienen consecuencias económicas reales.
En México la ley equivalente es la LFPDPPP (Ley Federal de Protección de Datos Personales en Posesión de los Particulares). Comparte los mismos principios fundamentales de GDPR: consentimiento, limitación de propósito, minimización de datos, exactitud, limitación de almacenamiento, integridad y confidencialidad, y responsabilidad demostrable. Si cumples bien con uno, estás muy cerca de cumplir con el otro.
Los siete principios que GDPR.eu enumera para el manejo de datos personales son una buena lista de verificación operativa, aplicable a cualquier negocio: legalidad, limitación de propósito, minimización, exactitud, limitación de almacenamiento, integridad y confidencialidad, y responsabilidad.
El NIST Cybersecurity Framework es, según el propio NIST, una guía diseñada para "ayudar a las organizaciones a entender y mejorar su gestión del riesgo de ciberseguridad". La versión actual es CSF 2.0, finalizada en 2024.
Aunque NIST está dirigido a organizaciones de cualquier tamaño, su utilidad práctica para un negocio pequeño está en su estructura: identificar activos, proteger, detectar incidentes, responder y recuperar. Para un dueño de negocio, esa secuencia es exactamente lo que debe poder explicarte tu proveedor de tecnología cuando le preguntes "¿qué pasa si nos atacan?".
Bandera roja 1: no puede explicar cómo se protegen los datos a nivel de base de datos.
Si la única respuesta es "el código tiene validaciones", falta una capa. Necesitas oír palabras como RLS, políticas de acceso, separación de roles, o equivalentes.
Bandera roja 2: no menciona OWASP ni NIST cuando preguntas.
Estos son los dos marcos más reconocidos del mundo en aplicaciones web y ciberseguridad. Un proveedor serio los conoce. Un proveedor que improvisa, no.
Bandera roja 3: no tiene política escrita de respaldos ni de respuesta a incidentes.
"Hacemos respaldos" no es una política. Una política dice con qué frecuencia, dónde se guardan, cómo se prueban, y qué pasa el día que la base de datos se corrompe o sufre un ransomware.
La mayoría de las filtraciones de datos en pequeños y medianos negocios no son ataques sofisticados. Son errores de configuración: una base de datos sin RLS, un endpoint sin autenticación, un respaldo público en la nube, una contraseña almacenada en texto plano. Todos prevenibles, todos invisibles para el dueño hasta que es demasiado tarde.
El servicio de Website Consulting de MerchandisePROS es precisamente la auditoría que cierra ese ángulo ciego. Revisamos tu sitio desde la perspectiva de UI/UX, Core Web Vitals y seguridad: validamos que tu proveedor esté aplicando los controles correctos, traducimos su trabajo a un reporte que tú puedas entender, y te damos las preguntas exactas que debes hacerle en la próxima reunión. No reemplazamos a tu desarrollador: lo auditamos, lo guiamos, y nos aseguramos de que tu negocio no sea el siguiente titular.
"Los dueños de negocio no necesitan aprender a programar. Necesitan aprender a hacer las tres preguntas correctas. Eso es todo lo que separa una empresa segura de una vulnerable."
- Diego Medina F, Fundador de MerchandisePROS
RLS es una regla a nivel de base de datos que limita qué filas puede leer cada usuario. Según la documentación de Supabase, funciona como si se agregara automáticamente una cláusula WHERE a cada consulta, de manera que un usuario solo ve los registros que le pertenecen.
Sí, si procesas datos de ciudadanos o residentes de la Unión Europea. Según GDPR.eu, la ley aplica incluso si tu empresa no está en la UE. Las multas máximas son de 20 millones de euros o el 4% de la facturación anual global, lo que sea mayor.
OWASP describe su Top 10 como un documento estándar de concientización para desarrolladores y seguridad de aplicaciones web. Lista los riesgos más críticos para aplicaciones web y es la referencia más usada por equipos de desarrollo serios en el mundo.
Tres señales claras: no puede explicar cómo se protegen los datos a nivel de base de datos, no menciona OWASP ni NIST cuando preguntas, y no tiene una política escrita de respaldos ni de respuesta a incidentes. Cualquiera de las tres justifica una segunda opinión.
El NIST Cybersecurity Framework (versión 2.0, finalizada en 2024) son lineamientos diseñados para ayudar a las organizaciones a entender y gestionar el riesgo de ciberseguridad. NIST lo describe como una guía "para industria, gobierno y organizaciones para reducir riesgos de ciberseguridad".
Una auditoría de Website Consulting te dice exactamente qué falta y qué preguntarle a tu proveedor.
Audita Mi Sitio Gratis Consulta Gratis