OWASP Top 10 (2025) explicado con ejemplos

Un usuario puede hacer o ver algo que no debería: los pedidos de otro cliente, un panel de administración, un archivo privado. Ejemplo: cambiar ?pedido=1052 por ?pedido=1053 en la dirección y ver el pedido de otra persona. Defensa: verificar los permisos en el servidor en cada pedido, nunca confiar en lo que manda el navegador.

Opciones por defecto, modos de depuración activos, carpetas listables, servicios que no se usan. Ejemplo: un WordPress con el modo de depuración encendido que muestra rutas del servidor, o una copia de la base de datos descargable desde el navegador. Defensa: configuración revisada y endurecida, sin nada que no haga falta. → Auditoría de seguridad web

Riesgos en lo que la aplicación usa de terceros: librerías, plugins, temas, dependencias y la forma en que se instalan y actualizan. Ejemplo: un plugin con una falla publicada que nadie actualizó, o un tema pirata con una puerta trasera. Defensa: inventario de componentes, actualizaciones al día y solo fuentes oficiales. → Plugins nulled

Datos sensibles sin cifrar o mal cifrados. Ejemplo: un sitio sin HTTPS, claves guardadas con algoritmos débiles o datos de tarjetas almacenados sin necesidad. Defensa: HTTPS en todo el sitio, algoritmos actuales y no guardar lo que no hace falta. → El aviso «No seguro» en WordPress

Datos que manda el usuario y que la aplicación interpreta como código: SQL, comandos del sistema o scripts en el navegador (XSS). Ejemplo: un buscador que arma la consulta a la base de datos pegando el texto del usuario. Defensa: consultas parametrizadas y escapar la salida. → Inyección SQL · Qué es XSS

El problema no es un error de programación, sino una decisión de diseño. Ejemplo: un proceso de recuperación de contraseña que se puede usar para averiguar si un usuario existe, o un cupón de descuento que se puede aplicar infinitas veces. Defensa: pensar en la seguridad desde el diseño, con casos de abuso además de casos de uso.

Inicios de sesión débiles. Ejemplo: sin límite de intentos, sin segunda clave, sesiones que no expiran o recuperación de claves insegura. Defensa: segunda clave, límite de intentos y sesiones bien gestionadas. → Cómo proteger wp-admin

La aplicación confía en código o datos que no verificó. Ejemplo: actualizaciones descargadas sin verificar su firma, o scripts de terceros cargados en el checkout sin control. Defensa: verificar la integridad de lo que se instala y limitar los scripts externos. → Seguridad en WooCommerce

Ataques que nadie ve porque no hay registros o nadie mira las alertas. Ejemplo: un sitio hackeado hace semanas sin que nadie lo note. Defensa: registros de accesos y cambios, y alertas que alguien lea.

Errores que, al fallar, dejan la aplicación en un estado inseguro o revelan información. Ejemplo: un error que muestra el detalle técnico de la base de datos, o un proceso de pago que, si falla a la mitad, da el pedido por pagado. Defensa: manejar los errores de forma controlada y que «fallar» signifique «denegar».