Confirma quién puede leer y modificar la base de datos
La primera comprobación consiste en entender si los datos tienen protección propia y si los permisos corresponden a las operaciones necesarias. En proyectos con Supabase, reviso RLS y políticas explícitas junto con los accesos concedidos. Pido pruebas de lectura y escritura con usuarios comunes, en lugar de aceptar solo que todo está activo.
Imagina una aplicación para una empresa que produce artículos promocionales personalizados. Hay pedidos, archivos de diseño y notas internas de producción. Una persona puede necesitar consultar el estado de su pedido sin poder leer observaciones destinadas al equipo. Esa distinción debe seguir siendo válida al consultar los datos por el recorrido previsto.
La revisión debe identificar las tablas relevantes, las operaciones permitidas y la evidencia de que los demás accesos se rechazan. Si la prueba utiliza una cuenta privilegiada, pide que se declare. Sus poderes pueden ser distintos de los de quienes utilizarán la aplicación y ocultar una configuración inadecuada.
También pido atención a formas alternativas de consultar los mismos datos, como vistas o funciones creadas para facilitar informes. Una protección aplicada a la tabla principal no evita tener que comprobar cómo se configuran esos caminos. El resultado debe permitir explicar quién puede obtener cada conjunto de información y por qué.
Esta regla entra en la planificación de la aplicación antes de programar porque depende de las relaciones entre datos y personas. Si solo empiezas a discutirlas al publicar, la revisión puede revelar una decisión de producto pendiente que ya atraviesa varios recorridos de la aplicación.
Para preparar el siguiente paso, consulta Seguridad de aplicaciones desarrolladas con IA.
Comprueba si el servidor decide los permisos y valores relevantes
La segunda comprobación busca decisiones importantes que confíen únicamente en el navegador. La identidad y la autorización deben confirmarse en el servidor y los valores que determinan una operación necesitan un origen válido. El contenido de un formulario es información recibida, no una prueba de que la acción esté autorizada.
En el pedido de artículos promocionales, el navegador puede mostrar un precio y una opción de aprobación. Eso no significa que deba determinar por sí solo el importe aceptado o quién puede aprobar. El sistema necesita consultar las reglas y la información verificadas que sostienen esa operación específica en el proyecto.
Pide al agente que identifique los campos recibidos del usuario que podrían afectar a una decisión: identidad, organización, nivel de acceso o estado de aprobación. La revisión debe mostrar cómo se trata cada uno. No basta con ocultarlos en pantalla si el procesamiento posterior confía en ellos sin una confirmación adecuada.
En las pruebas, interesa observar que una entrada incompatible con la regla se rechaza antes de producir efectos. Un mensaje visual puede ser correcto mientras el registro queda equivocado. Por eso, la evidencia debe incluir el resultado guardado o la ausencia de cambios, según el comportamiento esperado en ese caso.
Exige autorización sobre cada recurso solicitado
La tercera comprobación confirma que conocer el identificador de un recurso no basta para consultarlo o modificarlo. Cada solicitud debe relacionar la identidad verificada con el recurso y la acción deseada. La regla también debe aplicarse a adjuntos y exportaciones cuando transporten información que deba protegerse.
En el ejemplo de los artículos promocionales, dos empresas pueden tener pedidos en la misma aplicación. Un usuario legítimo de la primera sigue sin autorización para consultar el diseño enviado por la segunda. La revisión debe seguir el acceso al pedido y a su archivo, incluido el servicio donde se guarda.
Prepara datos ficticios que permitan demostrar esa separación en un entorno autorizado. La prueba debe mostrar que el acceso correcto funciona y el incorrecto se rechaza, sin utilizar documentos reales de clientes. Así puedes observar la regla con claridad y repetir la comprobación cuando el recorrido tenga cambios relevantes.
Es una aplicación concreta de probar antes de entregar una automatización. La validación sigue las consecuencias para el negocio: quién recibe qué y quién puede cambiar el estado del trabajo. El informe debe distinguir un control encontrado en el código de un comportamiento que realmente se ejercitó.
Busca secretos en lo que puede salir del servidor
La cuarta comprobación busca credenciales que puedan aparecer en el código compartido, los archivos enviados al navegador o los registros de ejecución. Las claves privadas deben permanecer en los mecanismos adecuados de configuración del servidor. Pido un informe que identifique ubicaciones y riesgo sin volver a imprimir el valor del secreto encontrado.
Una integración de envío de mensajes puede necesitar una credencial privada, pero el usuario de la aplicación no necesita recibirla. El servidor ejecuta la operación autorizada y devuelve el resultado necesario. Si la clave aparece en el código descargado por el navegador, que el repositorio sea privado no resuelve esa exposición.
Al preparar el entorno de trabajo con Claude Code, separa ejemplos de configuración y valores reales. Un archivo con nombres de variables y espacios vacíos puede orientar la instalación sin revelar credenciales. La revisión debe confirmar que los archivos con secretos no se incluyeron en el material destinado a compartirse.
Si se encuentra una credencial expuesta, retirar la línea del código no cierra el asunto. Hay que gestionar la credencial comprometida y los lugares donde pueda seguir disponible, con un responsable de sustituirla y asegurar la continuidad del servicio. El informe debe registrar acciones terminadas y pendientes, sin presentar una limpieza visual como resolución completa.
Valida las entradas antes de utilizarlas
La quinta comprobación sigue los datos recibidos por la aplicación y confirma que se aceptan solo en las condiciones previstas. Pido validación en el servidor, límites adecuados y reglas coherentes con la operación. La ayuda del formulario mejora la experiencia, pero no sustituye los controles que protegen el procesamiento y almacenamiento de información.
La cantidad de artículos promocionales debe respetar el tipo y los límites definidos para el pedido. Un archivo de diseño debe cumplir las condiciones de formato y tamaño aceptadas. Las reglas deben reflejar lo que puede gestionar el negocio, con una respuesta clara cuando la información recibida no permite completar la solicitud.
Validar no significa resolver todos los riesgos con una sola comprobación de texto. El contenido presentado como HTML, las consultas a la base de datos y los archivos cargados exigen un tratamiento apropiado al contexto de uso. Pide al agente que explique esos destinos y sus controles, sin convertir un filtro genérico en una garantía.
Al terminar, quiero cinco respuestas vinculadas a evidencia, con la versión revisada, las pruebas ejecutadas y las limitaciones conocidas. Un fallo que afecte a datos o acciones importantes debe resolverse antes de la publicación prevista. Después de corregir, repite las comprobaciones afectadas para que la decisión final corresponda al código que se entregará.