¿Cómo realizar una auditoría de seguridad de un sitio web?

Una auditoría de seguridad web va más allá de buscar malware. Evalúe conjuntamente la superficie de ataque, los permisos de usuarios, las dependencias, la configuración del servidor y la capacidad de respuesta a incidentes.

El objetivo de la auditoría no es eliminar todas las posibilidades, sino hacer visibles los riesgos y priorizarlos en función del impacto y la probabilidad.

Inventario de activos y de la superficie de ataque

Enumere dominios, subdominios, paneles de administración, endpoints de API, áreas de carga, scripts de terceros e integraciones.

Los entornos de preproducción olvidados o los subdominios antiguos pueden crear una superficie de ataque inesperada.

TLS y HTTPS

Verifique la cadena y validez de los certificados, las redirecciones HTTP y el contenido mixto.

Cabeceras de seguridad

Content-Security-Policy
X-Content-Type-Options
Referrer-Policy
Permissions-Policy
Restricciones de inclusión en marcos
Adecuación de HSTS

Autenticación

Una política de contraseñas sólida, 2FA y protección de fuerza bruta deben evaluarse en cuentas de usuarios administradores y críticos.

Autorización

Verifique que los usuarios solo pueden realizar las acciones permitidas por sus funciones. Una autenticación correcta no concede acceso a todos los datos.

Gestión de dependencias y parches

CMS, framework, plugin, tema y estado de soporte de paquetes deben ser comprobados. Los componentes no utilizados deben eliminarse.

Seguridad de cargas de archivos y datos de entrada

Verifique los tipos, tamaños y métodos de almacenamiento permitidos en las áreas de carga de archivos. Trate todos los datos introducidos por usuarios como no fiables.

Registros y preparación para incidentes

Registre los accesos fallidos, cambios administrativos, errores de aplicación y eventos críticos de seguridad para permitir su análisis posterior.

Cómo evaluar la preparación para producción

Que una página se abra en el navegador no significa que esté lista para producción. Defina criterios de aceptación medibles para el inventario de activos y de la superficie de ataque, TLS y HTTPS y las cabeceras de seguridad. Las referencias de disponibilidad, tiempo de respuesta, tasa de error, duración del despliegue y recorridos críticos permiten evaluar los cambios posteriores. Documente las diferencias de configuración entre preproducción y producción y limite, cuando sea posible, los cambios manuales directos en producción.

Evalúe conjuntamente la seguridad y el rendimiento. Un CDN o una caché pueden reducir la carga del servidor de origen, pero una regla incorrecta puede exponer contenido personalizado a otros usuarios. Un WAF o la limitación de solicitudes pueden reducir la superficie de ataque sin bloquear API e integraciones críticas. Pruebe los cambios con escenarios de tráfico realistas y monitorice de forma centralizada los registros de aplicaciones, del proxy inverso y el estado de los servicios externos.

Plan de despliegue y reversión

Antes de desplegar una nueva versión, actualizar el CMS o modificar la infraestructura, compruebe la disponibilidad de copias de seguridad de la base de datos y de los archivos. Prepare, si es necesario, un plan de mantenimiento o redirección del tráfico y defina un procedimiento de reversión para las versiones que incluyan migraciones de la base de datos. Tras el despliegue, no compruebe solo la página de inicio: las pruebas básicas de funcionamiento deben cubrir funciones críticas como el acceso, los formularios, la búsqueda, la API, los pagos y la captación de clientes potenciales. Así, la infraestructura web se trata como un sistema de producción operado de forma continua y no como un proyecto puntual.

Lista de verificación técnica de la infraestructura web

¿Están separados los entornos de preproducción y producción?
¿Puede revertirse el despliegue?
¿Se ha realizado una prueba de restauración de respaldo?
¿Se monitorizan los registros de la aplicación y del servidor web?
¿Se han verificado las cabeceras de seguridad y TLS?
¿Se han probado las reglas para omitir la caché?
¿Se siguen los ciclos de vida del entorno de ejecución y de las dependencias?
¿Las pruebas básicas de funcionamiento verifican los recorridos críticos de los usuarios?

Gestión de cambios, SLO y preparación para incidentes

Evalúe la calidad técnica más allá del lanzamiento inicial. Las actualizaciones pueden modificar dependencias, CMS, entorno de ejecución, caché, reglas de seguridad e integraciones. Siga los cambios mediante incidencias o registros de versiones para saber qué versión pasó a producción y cuándo. Defina procedimientos de reversión antes de los cambios críticos. Verifique especialmente los cambios relacionados con el inventario de activos y de la superficie de ataque, TLS y HTTPS y las cabeceras de seguridad mediante métricas comparables antes y después del despliegue.

Defina objetivos operativos medibles, como objetivos de nivel de servicio (SLO). La disponibilidad, el tiempo de respuesta P95, la tasa de errores 5xx, el éxito de formularios o transacciones críticas y los errores tras el despliegue reflejan el estado real de la aplicación. Un servidor accesible no basta: el inicio puede devolver HTTP 200 mientras fallan un formulario, pago, búsqueda o integración API. Complemente la monitorización técnica con comprobaciones sintéticas o pruebas básicas de los recorridos críticos del negocio.

Defina de antemano quién detecta los incidentes, qué equipo interviene primero y cuándo aplicar una reversión. Relacionar los registros, ID de solicitudes, momentos de despliegue y métricas de infraestructura con un mismo incidente agiliza el análisis de la causa. Tras restablecer el servicio, registre acciones técnicas o de proceso para evitar que se repita, en lugar de limitarse a la recuperación. Así, la infraestructura gana resiliencia con el tiempo.

El enfoque de B10 Digital Agency sobre infraestructura web

B10 Digital Agency trata los proyectos web como sistemas de producción, no solo como desarrollo de interfaces. La seguridad, el rendimiento, el despliegue, la integración, la experiencia de usuario y el mantenimiento sostenible se diseñan conjuntamente.

Preguntas frecuentes

¿Es la auditoría de seguridad la misma que las pruebas de penetración?

No. Las pruebas de penetración pueden formar parte de una auditoría; la auditoría también incluye comprobaciones de configuración y procesos.

¿HTTPS hace que el sitio sea completamente seguro?

No. TLS es solo un componente importante de la seguridad de las comunicaciones.

¿Es suficiente para añadir cabeceras de seguridad?

No. La seguridad de la aplicación, los accesos, las dependencias y el servidor debe abordarse conjuntamente.

¿Con qué frecuencia debe realizarse una auditoría de seguridad?

Según el riesgo y la frecuencia de los cambios, las auditorías pueden realizarse periódicamente y tras cambios importantes.

Haga que su infraestructura web sea segura y escalable

Conozca el enfoque de B10 Digital Agency para evaluar conjuntamente la seguridad, el rendimiento, el despliegue y las integraciones de su sitio.

Conozca el servicio de Desarrollo Web e Infraestructura Segura →