Proteger los datos con permisos explícitos
La base de datos debe tener reglas que indiquen quién puede consultar, crear, modificar y eliminar información. Esos permisos deben acompañar la estructura del negocio, incluida la separación entre usuarios y organizaciones. Una aplicación con inicio de sesión puede seguir exponiendo datos si las reglas de acceso son demasiado abiertas o no existen.
Imagina un portal donde dos empresas guardan solicitudes. La persona de la empresa A puede conocer la dirección de una solicitud de la empresa B, pero eso no le da autorización para consultarla. La separación debe existir donde se leen los datos, además de estar reflejada en la interfaz que ve cada persona.
Cuando usamos una base de datos con seguridad a nivel de fila, las reglas pueden restringir los registros disponibles para cada contexto. La documentación de RLS de Supabase explica ese mecanismo. El punto que llevo a la revisión es pedir reglas explícitas y comprobar su efecto con cuentas diferentes.
También hay que revisar las funciones y las formas indirectas de consultar datos. Una página puede usar una regla correcta mientras otra operación accede de forma privilegiada sin el filtro necesario. Por eso, la pregunta acompaña el recorrido completo: ¿qué información llega al usuario, por qué vía y con qué autorización?
Confirmar la autorización en el servidor en cada acción
El servidor debe decidir si una persona puede ejecutar una acción a partir de una sesión verificada y de los permisos guardados por el sistema. Los campos enviados por el navegador no pueden otorgar poderes administrativos. La interfaz ayuda a orientar al usuario, pero la decisión de permitir o rechazar debe seguir siendo válida fuera de ella.
Un botón oculto puede mejorar la experiencia al mostrar solo opciones pertinentes. Aun así, alguien puede intentar llamar directamente a la operación de editar una solicitud. El servidor necesita rechazar esa acción cuando la sesión no tiene permiso, independientemente de que la petición parezca igual a la que enviaría un administrador.
Una prueba útil utiliza dos cuentas con funciones diferentes. La primera puede consultar un registro; la segunda puede modificarlo. Comprueba ambos comportamientos e intenta editar con la cuenta de consulta. El resultado esperado debe estar escrito, para que futuros cambios de interfaz no eliminen la protección sin que nadie lo advierta.
Al construir la aplicación con Claude Code, reservé trabajo específico para revisar su seguridad antes de publicarla. Las cinco reglas de esta página también son criterios que exijo en mis proyectos. No basta con que la herramienta de IA diga que se ha ocupado de la seguridad: quiero evidencia del comportamiento.
Comprobar el acceso al recurso solicitado por su identificador
Cada operación que recibe el identificador de una solicitud, un archivo u otro recurso debe confirmar el acceso de la sesión a ese elemento. Conocer una dirección o un número no equivale a tener autorización. Esta comprobación debe existir en la lectura, edición, exportación y eliminación, según las acciones disponibles en la aplicación.
Piensa en la descarga de una propuesta. El usuario autenticado puede tener acceso a su propuesta y no a las demás. Si cambia el identificador en la dirección, el sistema debe rechazar el documento que no le pertenece. La misma lógica se aplica a imágenes privadas, audios, notas internas y resultados de una tarea de IA.
Este tipo de prueba es especialmente importante cuando la aplicación crece. Una primera página puede estar protegida y una nueva exportación reutilizar el identificador sin repetir la comprobación necesaria. Revisar las rutas por recurso ayuda a encontrar esas diferencias. La base de datos añade protección, y el código sigue validando la operación concreta.
En el caso de los agentes de IA empresariales, aplica el control antes de proporcionar el contexto al modelo. Si la sesión solo puede consultar determinadas solicitudes, la herramienta debe devolver únicamente esas solicitudes. El modelo no debe recibir información ajena con la instrucción de ignorarla.
Mantener las claves y credenciales fuera del contenido público
Las claves que permiten acceder a servicios privados deben permanecer en el servidor y fuera del código publicado, las páginas y los registros compartidos. Da a cada integración solo el acceso necesario. La revisión debe incluir archivos, historial de versiones y respuestas de la aplicación, porque una clave puede quedar expuesta por varias vías.
Una variable utilizada en el navegador puede ser vista por quien visita la web. Por eso, la petición a un servicio que exige un secreto debe pasar por una operación autorizada en el servidor. El navegador recibe solo el resultado permitido, sin recibir la credencial utilizada para ejecutar el trabajo en nombre de la aplicación.
Durante una demostración o una petición de ayuda, también conviene preparar el material. Una captura de pantalla puede mostrar una clave, un contacto o información de un cliente. En las clases hay decisiones sobre qué puedo mostrar. Ese cuidado debe continuar en la documentación y en los ejemplos enviados a herramientas de IA durante el desarrollo.
Si una credencial ha quedado expuesta, retirar el texto visible puede no ser suficiente: la clave debe sustituirse y deben revisarse los lugares donde se expuso. Para la prevención diaria, prefiero accesos específicos por proyecto y permisos limitados. Así, una integración de envío no necesita recibir poderes administrativos sobre toda la plataforma.
Validar las entradas y limitar el trabajo solicitado a la IA
La información recibida debe validarse antes de utilizarse, guardarse o mostrarse a otras personas. Define campos permitidos, formatos, tamaños y límites de uso. El contenido generado o importado también necesita tratamiento: una respuesta de IA sigue siendo una entrada que el sistema debe comprobar antes de ejecutar acciones con consecuencias.
En un formulario, comprueba los campos en el navegador para ayudar a la persona y de nuevo en el servidor para proteger la operación. La base de datos debe reforzar las reglas que le corresponden. En las subidas de archivos, comprueba su tipo y tamaño, guárdalos en el lugar adecuado y controla quién puede recuperarlos después.
Cuando muestras HTML, debes impedir que el contenido recibido ejecute código indebido. Cuando la IA lee una página o un documento, trata las instrucciones que encuentre en ese material como contenido externo. El proyecto OWASP para aplicaciones con modelos de lenguaje incluye riesgos como prompt injection y exposición de información sensible.
También defino límites de uso y de coste. Una funcionalidad que genera texto o procesa archivos puede ser objeto de abuso incluso sin exponer datos. El sistema debe poder rechazar peticiones excesivas, limitar el contexto enviado y hacer visible un fallo, en lugar de seguir consumiendo recursos sin control.
Pedir evidencia y mantener la revisión durante el proyecto
Una revisión útil entrega ejemplos de lo que se ha probado, resultados observados y límites que siguen sin resolverse. Repite las comprobaciones pertinentes cuando cambien accesos, integraciones o datos. La seguridad acompaña el mantenimiento de la aplicación, con responsables y criterios claros, porque un pequeño cambio puede abrir una vía que antes no existía.
Pido pruebas negativas: una cuenta que no puede leer la solicitud de otra, una operación administrativa rechazada y una subida de archivo fuera de los límites rechazada. También quiero comprobar que el usuario legítimo puede continuar su trabajo. Un sistema que lo bloquea todo no está listo solo porque haya dejado de exponer información.
En la documentación de seguridad de Claude Code, encontrarás precauciones sobre los permisos de la herramienta y el contenido no confiable. Distingo esa capa de la seguridad del producto que entregamos. El artículo sobre planificación de aplicaciones y la página de desarrollo con IA ayudan a conectar estas comprobaciones con la construcción.
Si quieres preparar a tu equipo para estas decisiones, consulta la formación de IA para empresas. Para hablar de la implementación y las necesidades del proyecto, presenta el contexto a SpartAds. Estos criterios orientan la conversación; una evaluación concreta depende siempre del sistema, de los datos y de las acciones que permite.