Auditoría de seguridad web: cómo comprobar la seguridad de tu sitio paso a paso

1. Sigue las protecciones a lo largo de un recorrido real

Empieza por una tarea que le importe a quien visita el sitio: crear una cuenta, consultar un pedido o enviar una solicitud de soporte. Enumera las páginas, los servicios y los registros de datos que intervienen. Así la revisión tiene un objetivo concreto y el trabajo técnico queda conectado con algo que la gente valora.

Cada capa cumple su parte. La red solo deja llegar a los servicios previstos. La aplicación reconoce la cuenta y aplica los permisos. El navegador recibe el contenido por una conexión cifrada y sigue las políticas de la respuesta. El alojamiento y las dependencias de software sostienen todo lo anterior. La guía de pruebas de seguridad web de OWASP (WSTG) ofrece una forma estructurada de revisar estas capas, y seguir un recorrido concreto ayuda a que cada especialista vea cómo encaja su trabajo en el conjunto.

Deja el alcance por escrito: qué dominios y entornos entran, con qué cuentas de prueba se trabaja y qué queda fuera. Revisa solo sistemas que sean tuyos o para los que tengas autorización, y usa un entorno de pruebas para cualquier comprobación que pueda modificar datos.

2. Relaciona cada protección con un resultado útil

Estos resultados ayudan a hablar de prioridades de forma constructiva. Un recorrido de cuenta que usa mucha gente puede merecer atención primero. También conviene revisar pronto los componentes compartidos, porque una corrección allí llega a muchas páginas a la vez. Prioriza según el recorrido afectado y el número de páginas que se benefician.

3. Da a las cuentas una experiencia coherente y segura

La autenticación determina con qué cuenta se está usando el servicio. La autorización decide después qué acciones y registros le corresponden. Describe estas reglas con lenguaje corriente: un cliente puede ver sus propias facturas, una persona de soporte gestiona las solicitudes que tiene asignadas y la persona que administra la cuenta configura los ajustes del equipo. Esa descripción se convierte en un plan de pruebas.

La guía de autorización de OWASP resume tres reglas útiles: las comprobaciones de acceso se hacen en el servidor, porque las del navegador pueden mejorar la experiencia, pero son fáciles de saltar; el acceso se deniega por defecto, y los permisos se validan en cada solicitud, venga de donde venga. Una prueba sencilla consiste en abrir una factura con la cuenta A, copiar su URL y abrirla con la cuenta B: el servidor debería denegar el acceso.

Revisa el registro, el inicio de sesión, la verificación, la recuperación y el cierre de sesión como una sola experiencia. Facilita el uso de gestores de contraseñas y usa etiquetas de formulario claras. Cuando la autenticación multifactor encaje con la cuenta, ofrece pasos de activación y recuperación comprensibles. La guía de autenticación de OWASP explica los controles de fondo. Prueba con cuentas dedicadas a cada rol y con datos de ejemplo fáciles de reconocer.

4. Haz que las observaciones técnicas sean fáciles de compartir

Una buena revisión anota qué se revisó y qué se observó. Incluye la página o el servicio exactos, el valor relevante de la respuesta, el comportamiento esperado y los pasos seguidos. En las notas compartidas usa datos de ejemplo y oculta las credenciales. Así el equipo de desarrollo, el de soporte y quien revise en el futuro tienen una referencia común.

Agrupa las observaciones por el componente responsable: varias páginas pueden compartir una misma configuración de sesión, y varias comprobaciones de red pueden describir un único servicio. En un sitio web público, HTTPS suele usar el puerto 443, y según la guía de configuración TLS de MDN el puerto 80 solo debería redirigir al mismo recurso en HTTPS; las API y los sitios que no son públicos deberían desactivar HTTP por completo. Registrar para qué sirve cada servicio expuesto convierte una lista de detalles técnicos en un mapa comprensible.

Valora cada observación por su efecto real. Que la cabecera Server muestre la versión del servidor no es necesariamente una vulnerabilidad en sí misma, como aclara la WSTG, y la referencia de MDN sobre Server añade que mantener el software al día con los parches es una medida más sólida que ocultar su nombre. Guarda también las comprobaciones superadas junto a las tareas pendientes, para que la revisión muestre las protecciones que ya funcionan.

5. Integra las buenas prácticas en el desarrollo diario

Usa componentes de autenticación consolidados, comprobaciones de permisos en el servidor y consultas parametrizadas a la base de datos: la guía de OWASP contra la inyección SQL sitúa las sentencias preparadas como primera defensa. Guarda las credenciales y claves de API en un almacén de secretos adecuado, con una persona responsable y un proceso de rotación.

Configura las cookies de sesión según el recorrido real de la cuenta. HttpOnly impide que el JavaScript de la página lea la cookie, aunque el navegador la sigue enviando con cada solicitud que corresponde, así que limita el robo de la cookie mediante XSS, pero no evita el XSS; Secure hace que solo viaje por HTTPS, y SameSite controla si se envía en solicitudes iniciadas desde otros sitios. La guía de gestión de sesiones de OWASP y su guía de cabeceras HTTP explican cómo estas políticas del navegador y de las cookies completan la base.

Mantén un registro breve de servicios con su finalidad, responsable, versión de software y forma de actualización. Cuando el equipo añada un proveedor de pagos o un widget de soporte, inclúyelo en ese registro y prueba el recorrido relacionado. Planificar las actualizaciones y tener a mano una configuración conocida facilita coordinar el mantenimiento, y un conjunto pequeño de prácticas aplicado igual en todas las plantillas da a quien construye el sitio un estándar compartido.

6. Establece un ritmo de revisión repetible

Fija una referencia inicial y repite las mismas comprobaciones después de cada cambio relevante. Usa el mismo objetivo, el mismo rol y el mismo recorrido para que las comparaciones tengan sentido. En los permisos, confirma que cada cuenta de prueba recibe exactamente el acceso previsto. En las políticas del navegador, completa los mismos formularios y retornos externos que usan los visitantes.

1. Anota las páginas, los roles y las acciones que entran en la revisión.
2. Inspecciona las respuestas entregadas y anota la protección observada.
3. Completa el recorrido previsto con cuentas de prueba representativas, incluido un intento de abrir datos de otra cuenta.
4. Registra el resultado, la persona responsable y la próxima ocasión de revisión.

Las buenas ocasiones para revisar son los cambios de alojamiento, de autenticación, de plantillas compartidas o de servicios conectados. La guía de autorización de OWASP añade que las pruebas unitarias y de integración de la lógica de permisos ayudan a que menos fallos de control de acceso lleguen a producción. Un registro fechado ayuda a quien se incorpora a entender el razonamiento detrás de la configuración y, con el tiempo, se convierte en un historial práctico de cómo se mantiene el sitio.

7. Convierte lo aprendido en una primera revisión pequeña

Elige una página pública y una acción de cuenta, y describe sus protecciones en una lista breve. Para la parte que se ve desde fuera, el snapshot gratuito de Sitelemetry ejecuta ocho comprobaciones pasivas sobre un origen público, sin crear una cuenta: resolución DNS; registros SPF, DMARC, CAA y MTA-STS; certificado TLS; cabeceras de seguridad HTTP; postura de redirección a HTTPS; señales de la tecnología usada; entrega (caché, compresión y CDN), y estado del dominio (WHOIS/RDAP). La redirección de HTTP a HTTPS solo se prueba si escribes una dirección http://; con un dominio o una dirección https:// se revisan el max-age de HSTS y el contenido mixto. Muestra una puntuación y hasta tres señales por las que empezar. No es un pentest ni la auditoría completa de seis áreas, y no inicia sesión en el sitio, así que las pruebas de cuentas y permisos de esta guía siguen siendo trabajo tuyo con tus cuentas de prueba.

Sigue con la guía sobre el certificado SSL/TLS y HTTPS para la capa de conexión, con la guía para comprobar las cabeceras de seguridad HTTP que envía tu sitio o con la guía de SPF, DKIM y DMARC para el correo del dominio. Antes de publicar un sitio nuevo o una migración, la checklist de seguridad para lanzar una web recorre estos ajustes públicos uno por uno. Si quieres revisar una sola capa, el comprobador gratuito de cabeceras de seguridad valora ocho cabeceras clave en la página de inicio y el verificador de SPF y DMARC consulta los registros de correo de un dominio.