# Cómo revisar la seguridad de una web en 2026: checklist práctico sin explotar vulnerabilidades > Para revisar la seguridad de una web en 2026, empieza por confirmar autorización y alcance, comprueba HTTPS y configuración pública, revisa cabeceras y exposición técnica, identifica CMS y dependencias visibles, verifica mantenimiento y rutas innecesarias, relaciona hallazgos con riesgos OWASP y prioriza por impacto y contexto. No intentes explotar fallos sin autorización. Si una señal afecta autenticación, permisos, datos o lógica de negocio, escálala a una revisión manual controlada. Canonical: https://kairoseth.com/es/blog/como-revisar-seguridad-web-2026 Product: [Kairoseth Security Inspector](https://kairoseth.com/products/security-inspector) Primary query: cómo revisar la seguridad de una web en 2026 Intent: informational Published: 2026-09-25 Updated: 2026-09-25 Geographic scope: España Geographic context: La guía añade contexto español mediante recursos de INCIBE para autodiagnóstico empresarial y conecta la revisión técnica de la web con una gestión de riesgo más amplia para pymes. No crea una página geográfica por sustitución de nombres: el contenido incorpora recursos y decisiones relevantes para organizaciones en España. Una revisión útil de seguridad web empieza por saber qué puede observarse de forma segura, qué señales requieren contexto y cuándo hay que escalar a una auditoría manual. Esta guía organiza la revisión con OWASP Top 10:2025, HTTPS, cabeceras, CMS, plugins y remediación verificable. Revisar la seguridad de una web en 2026 no consiste en lanzar un escáner y copiar una puntuación. Una web moderna combina servidor, CDN, DNS, CMS, plugins, scripts de terceros, formularios, analítica, pagos, APIs y cuentas administrativas. Cada capa puede introducir exposición, pero no todas las señales observables significan una vulnerabilidad explotable. La forma más útil de empezar es separar la observación pasiva de las pruebas activas: primero documentar qué está públicamente visible, después entender la relevancia y solo entonces decidir si una validación más profunda está justificada y autorizada. El OWASP Top 10:2025 refuerza esta disciplina al situar pérdida de control de acceso, configuración incorrecta y fallos de cadena de suministro entre los riesgos principales. Para pymes y equipos web, la meta práctica es construir un ciclo repetible: inventariar, observar, priorizar, corregir y verificar. ## 1. Empieza por el alcance y la autorización, no por la herramienta El primer control de cualquier revisión es administrativo: saber qué dominios, subdominios y servicios están incluidos y quién autoriza la evaluación. Incluso una comprobación técnicamente inocua puede generar confusión si se realiza sobre un activo de terceros, una infraestructura compartida o una URL que el equipo no controla. Documentar alcance evita que una revisión de la web corporativa termine afectando una pasarela de pago, un proveedor SaaS o un subdominio gestionado por otra empresa. Para una evaluación pasiva, el alcance puede limitarse a solicitudes normales y observación de respuestas públicas. Esa restricción debe quedar clara. No se incluyen fuerza bruta, bypass de autenticación, explotación, carga de payloads, enumeración agresiva ni pruebas que alteren datos. Si durante la observación aparece una señal que merece validación activa, se registra la evidencia y se propone un siguiente paso separado. Esta división protege al negocio y mejora la calidad del análisis porque obliga a distinguir lo que se sabe de lo que solo se sospecha. - Define activos autorizados antes de revisar. - Separa observación pasiva de validación activa. - Registra límites y dependencias de terceros. ## 2. Comprueba HTTPS, certificados y redirecciones como una cadena completa Una web puede mostrar el candado y seguir teniendo problemas de transporte o coherencia. Conviene revisar si HTTP redirige de forma consistente a HTTPS, si el certificado es válido para los nombres utilizados, si existen subdominios relevantes que quedan fuera del patrón esperado y si las redirecciones crean saltos innecesarios. También debe observarse si recursos importantes todavía se cargan por HTTP o si configuraciones antiguas producen contenido mixto. HSTS añade una política para que el navegador recuerde que un host debe utilizar HTTPS en conexiones futuras. Es útil, pero requiere entender el dominio antes de activar opciones como includeSubDomains o preload, porque una decisión incorrecta puede afectar servicios heredados. La revisión debería describir la situación actual y proponer pruebas seguras antes de cambios de alcance amplio. El objetivo no es acumular cabeceras, sino reducir rutas de comunicación inseguras sin romper servicios legítimos. ## 3. Revisa cabeceras de seguridad con contexto, no como una lista de casillas Las cabeceras de respuesta permiten controlar parte del comportamiento del navegador. Content-Security-Policy puede restringir qué recursos se cargan y desde dónde; HSTS refuerza el uso de HTTPS; otras políticas pueden limitar framing, reducir interpretaciones ambiguas de tipos MIME, controlar información de referer o definir capacidades disponibles para scripts y iframes. Una ausencia puede ser relevante, pero la importancia depende de cómo funciona la aplicación. CSP merece especial cuidado porque las aplicaciones modernas dependen de scripts, fuentes, analítica, pagos y widgets externos. Copiar una política estricta sin inventario puede dejar de funcionar una parte crítica del negocio. Una estrategia prudente consiste en identificar orígenes necesarios, reducir dependencias innecesarias y probar políticas de forma gradual. Cuando sea apropiado, el modo report-only puede ayudar a observar violaciones antes de aplicar bloqueo. El informe debe explicar qué se ha observado y qué validación necesita cada cambio. ## 4. Usa OWASP Top 10:2025 como mapa de riesgo, no como detector automático OWASP Top 10:2025 coloca pérdida de control de acceso en primer lugar, configuración de seguridad incorrecta en segundo y fallos de cadena de suministro de software en tercero. Estas categorías sirven para estructurar conversaciones de riesgo, pero una observación externa no puede demostrar todas ellas. Por ejemplo, una respuesta pública puede sugerir una configuración mejorable, mientras que un fallo real de autorización suele requerir usuarios, roles y acciones autenticadas para confirmarse. La regla práctica es mapear solo cuando exista evidencia razonable. Si el servidor expone una cabecera o una página de diagnóstico que no debería estar pública, la relación con una configuración incorrecta puede ser directa. Si se detecta un CMS o una biblioteca visible, eso no significa por sí solo que exista un fallo de cadena de suministro; se convierte en señal para revisar versión, procedencia, actualización e integridad. Evitar conclusiones automáticas reduce falsos positivos y ayuda a que el equipo confíe en el informe. ## 5. En WordPress y WooCommerce, inventaría dependencias y reduce lo que ya no necesitas Los CMS viven de extensiones. En WordPress una misma web puede acumular plugins de formularios, SEO, caché, pagos, cookies, backups, builders, analítica, traducciones y marketing. El problema no es el número por sí solo, sino perder la visibilidad sobre qué está activo, quién lo mantiene, cuándo se actualizó y qué permisos necesita. Un plugin abandonado o una integración que ya no se usa amplía superficie sin aportar valor. La revisión debe combinar señales públicas con inventario interno. Desde fuera puede observarse una huella tecnológica o una ruta típica, pero la confirmación de versión y estado debería hacerse en el panel, repositorio o sistema de mantenimiento cuando sea posible. Para WooCommerce también conviene revisar pasarelas, webhooks, cuentas con privilegios, integraciones ERP o CRM y scripts externos. Reducir dependencias no significa eliminar funcionalidad útil; significa conocer cada componente y poder justificar por qué está ahí. ## 6. Busca exposición innecesaria y configuraciones que facilitan reconocimiento Los detalles públicos pueden ser útiles para diagnóstico, pero no todos deberían permanecer abiertos en producción. Mensajes de error excesivos, páginas de prueba, directorios antiguos, archivos de backup accesibles, endpoints sin uso o información de entorno pueden ofrecer contexto innecesario sobre la infraestructura. La revisión pasiva debe buscar estas señales sin intentar acceder a datos protegidos ni adivinar rutas mediante enumeración agresiva. Cuando aparece una señal, el siguiente paso es comprobar si tiene una razón operativa. Un endpoint puede ser público porque alimenta una integración legítima; una cabecera puede incluir un identificador técnico requerido por un proveedor. La remediación correcta nace del contexto. A veces la acción es cerrar una ruta; otras veces es limitar información, aplicar autenticación, cambiar logging o simplemente documentar que la exposición es esperada. Una buena auditoría evita recomendaciones mecánicas y obliga a relacionar cada cambio con una necesidad real. ## 7. Trata autenticación y control de acceso como una revisión separada El hecho de que un login exista o de que una ruta responda no permite concluir que el control de acceso sea correcto. Broken Access Control sigue siendo la categoría principal del OWASP Top 10:2025 precisamente porque los problemas aparecen en decisiones de autorización: quién puede ver, modificar, exportar o ejecutar una acción. Confirmar esos límites requiere cuentas, roles, casos de prueba y autorización específica. Desde una revisión pasiva sí se pueden registrar elementos que merecen atención: formularios administrativos expuestos públicamente, ausencia de controles visibles de tasa, flujos de recuperación confusos o comportamientos de sesión que el equipo debería revisar. Pero el informe debe ser cuidadoso con el lenguaje. Una señal es un motivo para investigar, no una prueba automática de fallo. Cuando hay datos personales, pagos o información sensible, conviene que la validación activa se realice en un entorno controlado y con responsables claramente definidos. ## 8. Prioriza por riesgo y verifica cada remediación Una auditoría útil termina con decisiones, no con una lista interminable. Cada hallazgo debería incluir evidencia, alcance, confianza, impacto potencial, esfuerzo y una recomendación verificable. La prioridad cambia según el negocio: una exposición informativa en una landing puede ser menos urgente que una señal en checkout, login o un panel administrativo. También conviene agrupar mejoras para reducir cambios: por ejemplo, revisar de una vez política de HTTPS, cabeceras y configuración de proxy si comparten la misma capa técnica. Después de corregir, hay que volver a medir. Si se añadió HSTS, se revisa la respuesta real; si se cambió CSP, se confirma que las funciones críticas siguen operativas; si se eliminó una ruta, se verifica que dejó de estar disponible; si se actualizó un plugin, se documenta versión y fecha. Esta evidencia de cierre es valiosa para mantenimiento, proveedores y futuras auditorías. La seguridad web mejora cuando el equipo puede demostrar qué cambió, por qué y con qué resultado. ## 9. Complementa la revisión técnica con gestión de riesgo y recursos de INCIBE Una web no existe aislada del resto de la empresa. El riesgo real depende de qué información maneja, cuánto ingreso genera, qué procesos dependen de ella y qué alternativas existen si deja de funcionar. INCIBE ofrece herramientas de autodiagnóstico para empresas que ayudan a ampliar la mirada hacia correo, dispositivos, información, continuidad y otros activos. Utilizar ese marco junto a una revisión técnica evita que el equipo invierta todo su esfuerzo en una cabecera menor mientras ignora copias de seguridad, accesos o procedimientos críticos. Para una pyme española, el enfoque más sostenible suele ser progresivo. Primero se identifica la exposición visible y se corrigen configuraciones claras. Después se revisan cuentas, actualizaciones, backups, proveedores y procesos. Finalmente se decide qué partes justifican una auditoría especializada. Kairoseth Security Inspector encaja en esa primera capa y en la verificación recurrente: aporta evidencia sobre la superficie web, organiza prioridades y deja claro cuándo termina la automatización y cuándo debe intervenir una persona con contexto y autorización. ## Conclusiones - Define alcance y autorización antes de iniciar cualquier revisión. - Empieza por HTTPS, cabeceras, exposición y configuración observable antes de plantear pruebas activas. - Usa OWASP Top 10:2025 para contextualizar riesgos, no para etiquetar automáticamente cualquier señal. - En WordPress y WooCommerce, mantén un inventario vivo de plugins, integraciones y responsables. - Verifica las correcciones con evidencia de antes y después y conserva un ciclo recurrente de revisión. ## Sources - [OWASP Top 10:2025](https://top10.owasp.org/2025/) — OWASP Foundation - [Autodiagnóstico de ciberseguridad para empresas](https://adl.incibe.es/) — INCIBE - [Content-Security-Policy en MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy) — MDN Web Docs - [Strict-Transport-Security en MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Strict-Transport-Security) — MDN Web Docs ## External resources - [OWASP Top 10:2025](https://top10.owasp.org/2025/): Marco de referencia para los riesgos críticos de seguridad de aplicaciones web. - [Autodiagnóstico de INCIBE](https://adl.incibe.es/): Herramienta pública para iniciar una evaluación del riesgo de ciberseguridad del negocio. - [Guía CSP de MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy): Referencia técnica sobre Content-Security-Policy y su comportamiento en navegador. ## Producto relacionado - [Kairoseth Security Inspector](https://kairoseth.com/products/security-inspector): Evaluación pasiva y autorizada de la postura pública de seguridad de una web, con priorización y remediación. - [Solicitud personalizada](https://kairoseth.com/custom-requests)