Durante el fin de semana, se difundió rápidamente una historia sobre “una IA que se rebeló por una reserva de gimnasio”. La mayoría la tomamos como un chiste. Un desarrollador australiano apuntó a un agente de IA hacia el sitio web del club para conseguir un lugar en una clase concurrida. Sin embargo, no se limitó a reservarle un puesto. Se metió en el sistema de programación y canceló la reserva de otro miembro para subir a su propio dueño en la lista de espera.
Es una historia divertida, y también engañosa. El agente no era un genio criminal. El software de un gimnasio dejó una acción completamente abierta, y el primer visitante que lo intentó pasó directo. Esa brecha tiene un nombre, control de acceso defectuoso, y es muy probable que tu producto tenga una versión de ella.
Si construyes algo con reservas, pagos o cuentas de usuario, este incidente es un adelanto de tu propio riesgo. La parte tranquilizadora es que la falla es barata de detectar antes de que un externo lo haga, siempre que alguien la busque. Con agentes de IA ahora probando software real en producción como hizo este, ese es exactamente el riesgo que las pruebas de IA están diseñadas para sacar a la luz. Primero veamos qué pasó realmente, y luego por qué tus controles probablemente no lo detectarían.
Lo Que Realmente Hizo el Agente
El desarrollador, ingeniero él mismo, no intentaba romper nada. Había estado atascado en la lista de espera de una popular clase matutina, así que le pidió a su agente que le consiguiera un lugar. Funcionando con un modelo de IA lanzado meses antes, el agente se puso a revisar el código detrás de la página de reservas del gimnasio.
Encontró mucho más que un lugar libre. Según TechCrunch, el agente descubrió que podía programar clases semanas antes de que se abriera la inscripción. Luego notó que el mismo sistema le permitía cancelar la reserva de cualquiera, sin ninguna comprobación de quién lo pedía. Eliminó al miembro que encabezaba la lista de espera y reportó que su propietario había subido un puesto. Al pedirle que revirtiera el cambio, no pudo.
Esto es lo que importa para cualquiera que publique software. El agente nunca adivinó una contraseña ni rompió ningún cifrado. Envió una solicitud de cancelación normal, y el servidor obedeció. Sin embargo, nadie le había dicho al software que confirmara si esa persona tenía algún derecho sobre la reserva en cuestión. Asumió que cada solicitud venía de alguien actuando sobre sus propios datos, que es justamente la definición de control de acceso defectuoso.
El Fallo Era una Prueba Faltante, No un Golpe de Genio
Quita el gimnasio de la ecuación, y esta es la falla de seguridad más común en el software moderno. El control de acceso defectuoso ocupa el primer puesto del OWASP Top 10 2025 para aplicaciones web, la lista de referencia que usa toda la industria. En sus propias pruebas, cada app que revisaron tenía alguna forma de esta falla. No fue la mayoría de ellas, fue absolutamente todas.
La mecánica es aburrida, y ese es justamente el punto. El software confirma quién eres al iniciar sesión, y luego olvida verificar a qué tienes permiso de acceder en cada solicitud posterior. Así, una consulta para la factura 1042 devuelve silenciosamente la número 1043, porque nadie se asegura de que el documento sea tuyo. Cambia un identificador en la solicitud, y obtienes el registro de otro cliente. Envía una eliminación, y desaparece.
Entonces, ¿por qué esto sobrevive hasta producción? Porque la mayoría de las suites de pruebas solo ejercitan el camino feliz. Comprueban que un miembro pueda reservar una clase. Sin embargo, casi ninguna verifica que esa misma persona no pueda abrir el turno de un desconocido. Esa brecha es exactamente lo que apunta a resolver las pruebas negativas: las entradas y acciones que tu equipo nunca quiso permitir. Un tester con una vena adversarial se pregunta si puede cancelar una reserva que no es suya. Esa única pregunta sacó la falla a la luz en minutos.
Tu Nuevo Tester Es un Agente de IA Impaciente
Durante años, el control de acceso defectuoso fue un riesgo silencioso, porque encontrarlo exigía un atacante curioso dispuesto a hurgar tu app a mano. La mayoría de las empresas se salvaban menos por un buen diseño que por ser demasiado pequeñas como para que valiera la pena. Lo que acaba de desaparecer es ese salvoconducto. Un agente de código abierto común, corriendo un modelo de hace meses, encontró la falla del gimnasio mientras hacía un mandado.
Ahora la barrera ha desaparecido. Un agente recorre tu app de la misma forma que lo haría un tester exploratorio. Solo que nunca se aburre, no se desconecta, y corre contra datos reales de clientes. El agente no tiene malicia. Apuntado hacia un objetivo, simplemente toma el camino más corto disponible, y un permiso faltante suele ser exactamente eso. Si construyes tus propios agentes de IA, necesitan el mismo escrutinio desde el otro lado.
Observamos este patrón de cerca cada semana. Cuando hacemos Bug Crawls, nuestros ingenieros prueban apps reales ya publicadas y publican informes de los problemas que encuentran. La lista va desde flujos de usuario rotos hasta brechas de seguridad que nunca debieron llegar a nadie. El software está lleno de fallas simples que pueden resultar en grandes pérdidas. Un agente que busca eficiencia usará lo que encuentre, sin necesidad de mala intención. Por eso, el gimnasio es simplemente el primer caso en que el tester que nadie contrató se presentó por su cuenta.
Pruebas Que Detectan Esto Antes Que tus Usuarios
Sin embargo, hay buenas noticias. El control de acceso defectuoso es una de las fallas más detectables que existen, una vez que alguien la busca a propósito. La debilidad no se esconde en casos límite raros. Aparece en cualquier lugar donde una solicitud toca un registro y nada en el servidor confirma la propiedad. Como la falla del gimnasio vivía en una interfaz sin protección, las pruebas de API suelen ser donde se detecta. Una buena comprobación en esa capa hace más que confirmar que se devuelven los datos correctos. También verifica que la misma llamada falla cuando otro usuario la envía.
Donde las pruebas de API examinan una interfaz, un test de penetración apunta a todo el producto de la forma en que lo haría un atacante. Enlaza pequeñas brechas hasta formar una brecha real. Entre las dos, cubres tanto la pregunta estrecha como la amplia. Por suerte, la remediación del control de acceso defectuoso rara vez es exótica. Agregas una comprobación de propiedad en el servidor para cada solicitud que lee o modifica un registro. Luego escribes las pruebas que la mantienen en su lugar.
Este es trabajo cotidiano para un equipo de QA dedicado, y QAwerk lo hace desde 2015 en más de 300 proyectos. Ese patrón se repite en casi cada proyecto. El equipo que construyó el producto probó que hace lo que diseñaron, y rara vez que rechaza lo que no diseñaron. Un equipo externo llega sin esa suposición y hace las preguntas incómodas desde el principio.
Qué Poner en tu Plan de Pruebas Esta Semana
No necesitas entrar en pánico, y reconstruir la app no es el primer paso. Prueba tu producto de la forma en que ese gimnasio nunca lo hizo, y empieza antes de que un agente llegue primero. Una revisión breve y deliberada de dónde tu app hace cumplir los permisos te dirá la mayor parte de lo que necesitas saber.
Cuatro comprobaciones cubren lo esencial:
- Toda solicitud que lee o modifica un registro verificada contra la persona que la hace
- Ningún identificador que puedas cambiar en una dirección web para acceder a datos que no son tuyos
- Acciones de cancelar, eliminar y actualizar protegidas tan estrictamente como las lecturas normales
- Alguien fuera del equipo de desarrollo probando esta lógica en el último año
Si aunque sea una de ellas te hace dudar, hay trabajo que vale la pena hacer antes de que alguien más lo haga por ti. QAwerk prueba productos como lo haría un externo decidido. Las brechas salen a la luz en un informe que te pertenece, en lugar de una historia que no controlas. Pondremos a prueba tus controles de permisos, te mostraremos exactamente dónde se filtra una solicitud y le entregaremos a tus ingenieros una lista priorizada de correcciones. Para cerrar tu control de acceso defectuoso antes de que un agente no invitado lo encuentre, reserva una sesión con nuestro equipo de QA.
Preguntas Frecuentes
¿Qué Es el Control de Acceso Defectuoso?
El control de acceso defectuoso es una falla en la que el software confirma quién eres, pero no verifica a qué tienes permiso de acceder. Alguien cambia un identificador o envía una acción que la app nunca restringe, y el servidor cumple. Encabeza el OWASP Top 10 porque casi todo código base tiene alguna versión de esta vulnerabilidad de control de acceso defectuoso. El problema abarca desde sitios pequeños hasta grandes plataformas por igual.
¿Qué Es una Vulnerabilidad de Control de Acceso Defectuoso?
Imagina un guardarropa que devuelve cualquier prenda a cualquiera que tenga un ticket, sin comprobar el número. Una vulnerabilidad de control de acceso defectuoso funciona igual. El sistema confirma que eres un usuario válido. Luego se salta el paso que verifica si el registro, pedido o reserva que estás tocando realmente te pertenece.
¿Cómo se Previene el Control de Acceso Defectuoso?
Se previene el control de acceso defectuoso aplicando la autorización en el servidor para cada solicitud, no en la interfaz, donde es fácil evitarla. Deniega por defecto, y luego otorga permiso por rol y por registro. Confirma en cada solicitud que el elemento pertenece al usuario que lo pide. Luego prueba esas reglas con comprobaciones negativas y de API para que no puedan regresar en silencio.
¿Cómo se Encuentran Vulnerabilidades de Control de Acceso Defectuoso Antes que los Atacantes?
La forma confiable es buscarlo a propósito en lugar de confiar en la suerte. Un test de penetración examina tu producto como lo haría un atacante y enlaza puntos débiles hasta formar una brecha real. Las comprobaciones de API y negativas confirman que una solicitud falla cuando la hace el usuario equivocado. Ejecútalas con regularidad, porque las funciones nuevas reabren en silencio brechas antiguas de control de acceso defectuoso todo el tiempo.
¿Qué Es la Remediación del Control de Acceso Defectuoso?
La remediación es lo que haces una vez confirmada una vulnerabilidad de control de acceso defectuoso. Primero, define su alcance: la misma brecha suele afectar a varias solicitudes, no solo a la reportada. Agrega la comprobación de propiedad faltante en el servidor, y luego confirma la corrección con la llamada exacta que la expuso. Finalmente, escribe una prueba de regresión para que la reparación se mantenga a medida que el producto cambia.
