Un candado verde en la barra de direcciones no garantiza gran cosa. Cualquier sitio puede obtener certificados SSL gratuitos, incluidas las páginas de phishing. Verificar la seguridad de un sitio web requiere ir más allá de este simple indicador visual, examinando capas que ni el navegador ni el usuario promedio ven.
Seguridad de las API: el punto ciego de una auditoría de sitio web
Estás consultando una página web, ves texto, imágenes, un formulario. En segundo plano, esta página a menudo interroga varias API para recuperar o enviar datos. Estas interfaces programáticas se han convertido en un objetivo prioritario para los atacantes.
Los informes de 2024 confirman que los ataques dirigidos a las API representan una parte creciente de los incidentes en las aplicaciones web. El problema: la mayoría de las verificaciones clásicas se limitan a las páginas visibles. Los endpoints de API, en cambio, permanecen en la sombra.
Una auditoría efectiva comienza con un inventario completo de estos endpoints. Algunos se han creado para una necesidad puntual y luego se han olvidado. Otros están documentados de manera incompleta. Precisamente esos son los que presentan problemas, porque nadie piensa en verificar su autenticación o sus permisos.
Concretamente, cada punto de entrada de API debe ser probado individualmente. Se verifica que la autenticación funcione objeto por objeto (un usuario A no debe poder acceder a los datos del usuario B), que existan límites de tasa y que las API obsoletas hayan sido eliminadas. Varios herramientas permiten automatizar una parte de esta verificación de la seguridad de los sitios web, pero la revisión manual sigue siendo necesaria para los controles de autorización.
Priorizar las vulnerabilidades: por qué la puntuación CVSS no es suficiente
Cuando un escáner genera una lista de vulnerabilidades, cada una viene acompañada de una puntuación de gravedad (CVSS). La tentación es tratar primero las puntuaciones más altas. Este enfoque parece lógico, pero omite un dato capital: los atacantes explotan sobre todo vulnerabilidades conocidas y documentadas, no necesariamente las más sofisticadas.
La CISA mantiene un catálogo llamado Known Exploited Vulnerabilities (KEV). Este catálogo enumera las vulnerabilidades que se explotan activamente en la naturaleza. Una vulnerabilidad con una puntuación CVSS media pero presente en este catálogo merece una corrección inmediata. En cambio, una vulnerabilidad teórica con una puntuación muy alta pero nunca explotada puede esperar.
Para una verificación realmente útil, cruza tres criterios:
- La gravedad técnica dada por la puntuación CVSS, que mide el potencial de daño de la vulnerabilidad.
- La presencia en el catálogo KEV de la CISA, que indica si la vulnerabilidad está siendo explotada activamente por atacantes.
- La exposición real del componente afectado: un servicio accesible desde internet es más urgente que una herramienta interna detrás de un VPN.
Cruzar gravedad técnica, explotación activa y exposición real cambia radicalmente el orden de prioridad de las correcciones. Sin este filtrado, una empresa puede pasar semanas en una vulnerabilidad teórica mientras una brecha explotada permanece abierta.
Componentes de código abierto y modelos de IA en el análisis de seguridad
La mayoría de los sitios web modernos se basan en bibliotecas de código abierto. Un CMS, un marco de JavaScript, un módulo de pago: cada uno incluye código de terceros con sus propias vulnerabilidades potenciales.
Verificar estos componentes requiere un inventario preciso, a menudo llamado Software Bill of Materials (SBOM). Este documento lista cada dependencia, su versión y su estado de mantenimiento. Un componente abandonado por sus mantenedores es un riesgo silencioso: ninguna actualización corregirá las vulnerabilidades descubiertas después del abandono.
Las funcionalidades que integran inteligencia artificial plantean un problema adicional. Un modelo de IA expuesto a través de una API puede ser manipulado por consultas diseñadas para extraer datos de entrenamiento o eludir filtros. Estos vectores de ataque aún están mal cubiertos por los escáneres clásicos.
Verificar la configuración del servidor y los encabezados HTTP
Antes incluso de buscar vulnerabilidades en el código, la configuración del servidor a menudo revela problemas simples de corregir. Los encabezados HTTP, por ejemplo, controlan cómo el navegador interactúa con el sitio.
Un encabezado Content-Security-Policy bien configurado bloquea la mayoría de los ataques XSS. En cambio, algunos encabezados que antes se recomendaban ahora están obsoletos. X-XSS-Protection, por ejemplo, ya no es útil en los navegadores modernos según la documentación de MDN. Copiar y pegar una configuración encontrada en un foro de 2018 puede dar una falsa sensación de seguridad.
Los puntos a verificar del lado del servidor:
- El protocolo HTTPS está activo con un certificado válido, y las redirecciones HTTP a HTTPS funcionan sin bucles.
- Los archivos sensibles (copias de seguridad, archivos de configuración, directorios .git) no son accesibles públicamente.
- Los encabezados de seguridad están actualizados y adaptados al contexto del sitio, no simplemente copiados de un modelo genérico.
- Los mensajes de error del servidor no divulgan información técnica (versiones de software, rutas de archivos).
Verificación después de la corrección: el paso que la mayoría de las empresas omiten
Detectar una vulnerabilidad, corregirla, pasar a la siguiente. Este ciclo parece completo, pero falta un paso formal: confirmar que la corrección funciona realmente.
Los datos de 2024 muestran que las vulnerabilidades conocidas permanecen abiertas durante períodos prolongados, incluso en empresas equipadas con escáneres. El parche se ha desplegado en un entorno de prueba pero no en producción. O bien la actualización se ha aplicado, pero una versión vulnerable del componente sigue funcionando en otro servidor.
La verificación después de la corrección debe incluir un nuevo escaneo centrado en la vulnerabilidad tratada, una verificación manual de que el parche no ha creado regresiones (una funcionalidad rota, un formulario que ya no valida las entradas) y un control de que las versiones vulnerables han sido eliminadas de todos los entornos expuestos.
Este paso transforma un informe de auditoría en una mejora medible. Sin él, el informe sigue siendo un documento PDF archivado en una carpeta, y la vulnerabilidad sigue siendo explotable.
