Seguridad web: OWASP Top 10 y checklist pragmática para equipos

Según el OWASP Top 10, las medidas más importantes para aplicaciones web seguras son manejables: comprobar los permisos en el servidor en cada petición, validar las entradas y parametrizar las consultas, proteger bien sesiones y contraseñas, reforzar la configuración, mantener actualizadas las dependencias y registrar los eventos relevantes para la seguridad. Las vulnerabilidades rara vez nacen de ataques exóticos, sino de patrones conocidos: una comprobación de permisos ausente, una entrada sin filtrar, una biblioteca obsoleta.

Este artículo muestra cómo usar el OWASP Top 10 como guía, qué bases necesita todo proyecto web y cómo proceder con una checklist priorizada, sin tener que lanzar de entrada un gran proyecto de seguridad.

Qué es el OWASP Top 10 y qué no es

El Open Worldwide Application Security Project (OWASP) es una comunidad sin ánimo de lucro que publica guías de libre acceso sobre seguridad de aplicaciones. Su publicación más conocida es el OWASP Top 10: un resumen de las categorías de riesgo más críticas para aplicaciones web, que se revisa con varios años de intervalo. En owasp.org puede ver qué edición es la vigente; las categorías solo cambian en matices de una edición a otra. Desde 2021 encabeza la lista Broken Access Control (control de acceso defectuoso); la inyección, la mala configuración y los componentes vulnerables son problemas permanentes.

Importante: el Top 10 no es un estándar de auditoría completo, sino una orientación sobre los temas que no pueden faltar en ningún proyecto. Quien quiera auditar de forma sistemática recurre al OWASP Application Security Verification Standard (ASVS), que ordena los requisitos en tres niveles, y a las OWASP Cheat Sheets con indicaciones concretas de aplicación. Si incorpora funciones de IA, aparecen riesgos propios; OWASP mantiene listas aparte para ellos.

Primero lo básico, después el test de penetración

No todo proyecto necesita de inmediato un test de penetración. Pero todo proyecto necesita bases sólidas: sesiones seguras, protección CSRF, validación de entradas, cabeceras HTTP seguras y actualizaciones periódicas de las dependencias. Un pentest sobre una aplicación sin esa base encuentra sobre todo problemas que se habrían evitado con medidas estándar, y el tiempo de los auditores se paga igualmente. Un pentest resulta útil antes de poner en producción aplicaciones sensibles y tras cambios importantes.

Los principales campos de riesgo y qué ayuda contra ellos

Control de acceso

Un ejemplo clásico: en un portal de clientes, un usuario con sesión iniciada cambia el número de factura en la barra de direcciones y de repente ve la factura de otro cliente. La solución: cada petición se comprueba en el servidor para saber si el usuario puede ver o modificar precisamente esos datos. Esto vale también para las funciones, porque un menú de administración que solo se oculta en el frontend sigue accesible a través de la URL. Rige, en general, «denegar por defecto»; los permisos se conceden de forma selectiva. Es fácil de probar: use dos cuentas con roles distintos e intente consultar los datos de la otra.

Mala configura­ción

Modo de depuración activo en el sistema en producción, contraseñas por defecto, mensajes de error detallados con información técnica, almacenamiento en la nube de acceso público o interfaces de administración accesibles desde internet: muchas brechas no surgen en el código, sino en la configuración. Ayudan las configuraciones base reforzadas, versionadas y desplegadas de forma automática: así rige el mismo nivel en desarrollo, pruebas y producción, y las desviaciones llaman la atención.

Inyección y cross-site scripting

Si las entradas llegan sin comprobar a consultas de base de datos o a comandos del sistema, los atacantes pueden inyectar los suyos. Las consultas parametrizadas, un ORM bien empleado y la validación en el servidor de todas las entradas cierran esa puerta. En el cross-site scripting (XSS) se introduce código de script ajeno en su página, que se ejecuta en el navegador de otros usuarios. Los frameworks modernos escapan la salida por defecto; el peligro aparece donde los desarrolladores eluden esa protección a propósito. Algo parecido ocurre con las peticiones desde el servidor, como una importación de imágenes por URL: permita solo destinos autorizados, o el servidor podrá usarse para consultar sistemas internos.

Autentica­ción y sesiones

Las cookies de sesión deben establecerse con los atributos HttpOnly, Secure y SameSite, renovarse tras el inicio de sesión e invalidarse en el servidor al cerrar sesión. Las contraseñas nunca deben guardarse en texto plano en la base de datos, sino con un hash generado por un método pensado para ello, como Argon2id o bcrypt; permita frases de contraseña largas en lugar de reglas de caracteres complicadas y rechace las contraseñas conocidas por haberse filtrado. Además, deben ser norma los tokens CSRF en los formularios, la limitación de intentos de inicio de sesión y, en aplicaciones sensibles y para administradores, la autenticación de dos factores. Las passkeys son una alternativa moderna y resistente al phishing.

Criptografía y secretos

Utilice versiones actuales de TLS (como mínimo TLS 1.2, preferiblemente 1.3) y cifre también los datos sensibles en reposo. Las credenciales y las claves no deben estar nunca en el repositorio de código, sino en una gestión de secretos; un escaneo en el pipeline encuentra las claves subidas por error antes de que lo hagan otros.

Dependencias y cadena de suministro

Las aplicaciones modernas se componen en gran parte de bibliotecas ajenas. Los escaneos automáticos en el pipeline de compilación avisan de vulnerabilidades conocidas, las versiones fijadas hacen trazables las compilaciones y un ritmo regular de actualizaciones evita que se acumulen lastres. Como mostró Log4Shell a finales de 2021, una sola biblioteca puede afectar a miles de aplicaciones: quien mantiene una lista de materiales de sus componentes (SBOM) sabe pronto si está afectado.

Registro y supervisión

Los ataques que nadie detecta pueden prolongarse durante mucho tiempo. Los eventos relevantes para la seguridad, como inicios de sesión fallidos o cambios de permisos, deben registrarse de forma centralizada, protegerse frente a manipulaciones y supervisarse, sin escribir contraseñas ni otros datos sensibles en los registros. También forman parte las copias de seguridad probadas: una copia cuya restauración nunca se ha ensayado es, en caso de emergencia, una esperanza y no una medida.

Cabeceras HTTP seguras: endurecer la CSP paso a paso

Las cabeceras HTTP son una palanca barata con gran efecto. Estas deben estar en todo sitio en producción:

Cabecera	Efecto	Nota
Strict-Transport-Security	obliga al navegador a usar HTTPS	activar solo cuando todos los subdominios admitan HTTPS
Content-Security-Policy	limita desde dónde se cargan scripts, imágenes y frames; segunda línea de defensa contra XSS	empezar en modo de informe
X-Content-Type-Options	evita que se interpreten mal los tipos de archivo (nosniff)	servir correctamente los tipos de archivo
Referrer-Policy	limita qué información de la URL se transmite a otros sitios	elegir un valor restrictivo, como strict-origin-when-cross-origin
Permissions-Policy	desactiva para la página funciones del navegador como la cámara o la ubicación	habilitar solo lo necesario
frame-ancestors (en la CSP)	protege frente a la incrustación en sitios ajenos (clickjacking)	sustituye a la antigua X-Frame-Options

La Content Security Policy (CSP) es la cabecera más potente, pero también la más exigente. La introducimos paso a paso: primero en modo de solo informe (Content-Security-Policy-Report-Only), para ver qué scripts y fuentes se usan realmente, y después con reglas cada vez más estrictas, a ser posible con nonces en lugar de scripts en línea permitidos de forma general. Así la CSP protege sin bloquear funciones sin que nadie lo note. Después compruebe las cabeceras con un escáner en línea o con las herramientas de desarrollo del navegador.

Modelado de amenazas y priorización: encontrar riesgos de forma estructurada

Qué amenazas son realmente relevantes para su aplicación lo aclaramos en un taller estructurado de modelado de amenazas, que suele durar de dos a cuatro horas. Cuatro preguntas guía marcan el marco: ¿Qué estamos construyendo? ¿Qué puede salir mal? ¿Qué hacemos al respecto? ¿Hemos analizado con suficiente rigor? El resultado es una lista priorizada de medidas que pasa directamente al backlog. Además de los desarrolladores, deben participar personas del área de negocio y de operaciones, porque conocen los procesos y los datos que más merecen protección.

Ejemplo práctico: el portal de clientes de un mayorista

Un mayorista gestiona un portal en el que los distribuidores consultan pedidos, precios y facturas. En el taller se ve que los mayores riesgos no son los exóticos: los números de factura figuran en las URL, un frontend de administración antiguo es accesible desde internet con acceso por defecto, una biblioteca para generar PDF no se actualiza desde hace años y no se registran los inicios de sesión fallidos. La siguiente valoración es un ejemplo de priorización:

Medida	Esfuerzo	Efecto	Momento
Comprobación de permisos por objeto para facturas y pedidos	medio	alto	de inmediato
Proteger el acceso de administración: eliminar el acceso por defecto, 2FA y restringir el acceso	bajo	alto	de inmediato
Actualizar las dependencias e incorporar un escaneo al pipeline	medio	alto	a corto plazo
Configurar las cabeceras de seguridad e iniciar la CSP en modo de informe	bajo	medio	a corto plazo
Registrar los eventos de inicio de sesión y configurar alertas	medio	medio	siguiente fase de ampliación
Test de penetración para verificar	alto	alto	tras la aplicación, antes de poner en producción cambios importantes

La seguridad en el proceso de desarrollo y de cara al cliente

Las auditorías puntuales caducan pronto. La seguridad web duradera surge cuando forma parte fija del día a día del desarrollo:

• Definition of done: los puntos relevantes para la seguridad, como la comprobación de permisos y la validación de entradas, forman parte de cada aceptación.
• Revisiones de código: los cambios en el inicio de sesión, los permisos o los flujos de pago se revisan con especial cuidado.
• Comprobaciones automáticas: los escaneos de dependencias y el análisis estático se ejecutan en cada compilación del pipeline CI/CD.
• Mantenimiento periódico: las actualizaciones se planifican a intervalos fijos y no solo ante una urgencia.

Sobre todo en el negocio B2B, los clientes suelen exigir pruebas de seguridad, a menudo en forma de extensos cuestionarios sobre control de acceso, cifrado, actualizaciones, copias de seguridad y registro de eventos. La presión crece: la Directiva NIS2 obliga a determinadas empresas a tener en cuenta también la seguridad de su cadena de suministro, de modo que, como proveedor, puede verse afectado indirectamente. Aplicamos los requisitos de OWASP a su arquitectura concreta y planificamos desde el principio qué pruebas harán falta para auditorías o cuestionarios de clientes. Eso ahorra tiempo y discusiones más adelante. Las cuestiones de protección de datos están estrechamente ligadas; una introducción es nuestro artículo RGPD y tracking.

La checklist pragmática para su equipo

Base para todo proyecto web

• Comprobar los permisos en el servidor en cada petición
• Validar las entradas en el servidor y parametrizar las consultas
• Escapar la salida según el contexto
• Activar cookies de sesión seguras y protección CSRF
• Guardar las contraseñas con hash Argon2id o bcrypt y aplicar limitación de intentos en los inicios de sesión
• Forzar HTTPS y configurar las cabeceras de seguridad
• Escanear las dependencias de forma automática y actualizarlas con regularidad
• Excluir el modo de depuración y los accesos por defecto en producción y mantener los secretos fuera del repositorio

Ampliada para aplicaciones sensibles

• Autenticación de dos factores para usuarios y administradores
• Iniciar la CSP en modo de informe y endurecerla paso a paso
• Registrar y supervisar los eventos de seguridad y restaurar copias de seguridad con regularidad
• Taller de modelado de amenazas antes de ampliaciones importantes
• Facilitar una dirección de contacto para avisos de seguridad (security.txt)
• Test de penetración antes de la puesta en producción o tras cambios importantes

Cómo le ayuda Nano Concepts

La seguridad web no tiene por qué ser un gran proyecto. Quien usa el OWASP Top 10 como guía, aplica las bases con coherencia y prioriza los riesgos de forma estructurada cierra muchas brechas típicas antes de que se conviertan en un problema. Para los sitios WordPress rigen reglas adicionales que hemos resumido en el artículo proteger WordPress.

¿Quiere saber cómo está la seguridad de su aplicación web? Con nuestra área de servicio seguridad web le apoyamos desde el análisis de la situación hasta la aplicación; las actualizaciones periódicas y la supervisión pueden planificarse de forma estable mediante mantenimiento y soporte. La primera consulta es gratuita.