¿Por dónde se ataca una aplicación web?
Casi siempre por el mismo sitio: donde la aplicación confía en datos que vienen del usuario. Las familias dominantes son la inyección (SQL, comandos, plantillas), el cross-site scripting, los fallos de control de acceso —pedir el recurso de otro y que el servidor lo entregue—, la falsificación de peticiones del lado del servidor y los errores de configuración. El OWASP Top 10 las ordena por prevalencia e impacto.
El control de acceso roto es el número uno
No es el fallo más espectacular, pero sí el más extendido: la aplicación comprueba que el usuario ha iniciado sesión y da por hecho que entonces puede ver lo que pide. Cambiar un identificador en la URL, un rol en una petición o acceder directamente a una ruta de administración sin pasar por el menú sigue funcionando en una cantidad sorprendente de aplicaciones, y los escáneres no lo detectan porque la respuesta es un 200 perfectamente normal.
¿Cómo se reducen estos riesgos?
Validar y codificar siempre en el servidor, nunca solo en el navegador; usar consultas parametrizadas en vez de concatenar cadenas; centralizar la autorización en una capa común y comprobarla contra la identidad de la sesión; mantener las dependencias al día, que son el origen de buena parte de las brechas; y añadir cabeceras como CSP, que no arreglan un fallo pero limitan mucho lo que un atacante puede hacer con él.
