Ocultar no es bloquear: por qué esconder un botón no protege tus datos

En dos líneas: que alguien no vea un botón no quiere decir que no pueda usar lo que hay detrás. Si el dato sigue estando al alcance por otro camino, el control es decorativo. Aquí tienes tres casos nuestros donde eso pasó, la trampa del control que falla abierto, y tres preguntas para comprobar si te pasa a ti.

La puerta tapada y la puerta tapiada

Imagina una puerta en la pared de tu oficina que no quieres que use nadie.

Puedes colgar un cuadro delante. La puerta desaparece de la vista, nadie la usa, y el asunto parece resuelto. O puedes tapiarla: quitar el marco, cerrar el hueco, que deje de ser una puerta.

Las dos soluciones se ven igual desde el pasillo. Pero solo una es una pared.

Con el software pasa lo mismo. Cuando alguien te dice que un usuario "no puede" hacer algo, merece la pena preguntar dónde vive ese "no puede".

Casi siempre vive en la interfaz. El botón no aparece, la pestaña no se ve, el campo está en gris. Y ahí se da el tema por cerrado, porque en la práctica nadie lo hace.

El problema es que la interfaz es solo una de las entradas. Por debajo de cualquier aplicación hay una API (la puerta por la que los programas hablan entre ellos, sin pasar por ninguna pantalla), y esa API atiende peticiones vengan de donde vengan. Si el permiso se resolvió únicamente pintando o no pintando un botón, la operación sigue disponible para quien sepa pedirla directamente contra la API. Y no hace falta un atacante sofisticado: en muchos casos basta con abrir las herramientas de desarrollo que trae cualquier navegador y mirar qué peticiones lanza la propia aplicación.

De ahí salen dos situaciones que se parecen mucho por fuera y no tienen nada que ver por dentro:

• Prohibido: el sistema podría hacerlo, pero se confía en que nadie lo pida.
• Impedido: el sistema no puede hacerlo aunque se lo pidan.

Solo lo segundo es un control. Lo primero es una expectativa de buen comportamiento.

Tres casos nuestros, y ninguno era teoría

Estos no son ejemplos de manual. Son fallos de nuestros propios sistemas, encontrados en revisiones internas y corregidos.

1. Las notas de una evaluación las podía modificar el propio evaluado. Tenemos una plataforma donde los equipos comerciales entrenan con clientes virtuales, y cada sesión termina con una puntuación por competencia. En la interfaz nunca hubo forma de tocarlas: ni botón, ni campo, ni manera de intentarlo. Pero al auditar los permisos de la base de datos apareció que cada usuario tenía permiso de escritura sobre su propio registro, incluidas las columnas de evaluación. Nadie lo hizo nunca. Cualquiera podría haberlo hecho, y además sin dejar rastro evidente. Se revocó el permiso columna por columna: esas notas las escribe el sistema con sus propias credenciales, no la persona.

2. El directorio del equipo se podía volcar sin haber iniciado sesión. Había una función interna que devolvía nombre, departamento y puesto de toda la plantilla, y estaba accesible al perfil anónimo, es decir, al de cualquiera que llegue sin identificarse. No aparecía en ninguna pantalla pública, pero respondía a quien la llamara. Revocada.

3. Una copia de seguridad la podía disparar cualquiera. El proceso que exporta nuestro CRM a un almacenamiento externo se autorizaba con la clave pública de la aplicación. Y "pública" aquí es literal: esa clave viaja dentro del código de cualquier web que use el sistema, y está pensada para ser visible. No exponía datos, porque el volcado va a nuestro propio almacén, pero permitía que alguien de fuera lo ejecutara a voluntad, con el consumo que eso implica. Ahora exige un token que solo vive en el servidor.

Los tres comparten la misma forma: el control estaba donde se mira, no donde se decide.

El control que falla abierto

Hay un segundo problema, más silencioso, y es el que de verdad conviene entender porque no avisa.

Un control puede estar bien colocado y aun así comportarse mal el día que algo se rompe.

Piensa en el portero de un edificio de oficinas. Tiene un listado de quién puede subir a cada planta. Un día el listado no le llega. ¿Qué hace?

• Falla cerrado: ante la duda, no deja pasar. Alguien protesta porque no puede subir a su propia oficina, y te enteras el mismo día.
• Falla abierto: ante la duda, deja pasar. Nadie protesta y todo va suave.

En software es exactamente igual: una comprobación de permisos que consulta un servicio y no recibe respuesta puede denegar por defecto o permitir por defecto. La segunda opción es la peligrosa, precisamente porque no genera ninguna señal. El sistema parece funcionar mejor que nunca. Los controles que fallan abierto no se descubren usando el producto: se descubren en una auditoría, o cuando ya ha pasado algo.

Y con agentes de inteligencia artificial esto se multiplica, por un motivo muy concreto: un agente insiste. Una persona que se topa con un error lo intenta otra vez, quizá una tercera, y luego llama a alguien. Un agente reintenta de forma sistemática, prueba rutas alternativas y sigue adelante sin cansarse. Un control que deja pasar el 1% de las veces, delante de algo que lo intenta mil veces, ha dejado de ser un control.

Tres preguntas para comprobarlo en tu empresa

No necesitas un proyecto ni saber programar. Necesitas hacer tres preguntas a quien lleve tus sistemas, y escuchar bien la respuesta.

1. Coge un permiso que des por hecho. Por ejemplo: "un comercial no puede ver las cuentas de otro comercial". Pregunta: ¿eso está impedido en el servidor, o solo oculto en la interfaz?

2. Pregunta qué pasa cuando la comprobación falla. Si nadie sabe contestarte, la respuesta suele ser que falla abierto. Nadie diseña un sistema para que falle abierto: simplemente no se decidió, y por defecto quedó así.

3. Pide que te lo demuestren. Un control real se puede enseñar: se intenta la operación contra la API, delante de ti, y el sistema la rechaza. Si la demostración es "mira, el botón no está", no hay control.

Delante de un auditor, la frase que vale no es "se lo hemos prohibido". Es "no puede". Y esa frase hay que poder respaldarla con una prueba reproducible, no con una captura de pantalla.

Lo importante, en una frase

Un control fiable es el que quita la capacidad, no el que la prohíbe. Lo demás es una norma de convivencia: útil mientras todo el mundo colabore, inútil el día que alguien no lo haga, o el día que un agente automatice el intento mil veces seguidas.

De los tres casos de arriba, ninguno lo encontró un atacante. Los encontramos nosotros, mirando dónde vivía cada permiso. Ese es el ejercicio, y sale bastante más barato hacerlo antes que después.

¿Quieres saber cómo se gobierna un equipo de agentes con controles que aguantan delante de un auditor? Descarga nuestra guía de Equipos Digitales.

---

Contenido desarrollado con apoyo de la IA y supervisado por el equipo editorial de Digital Transformations.