Protección de servicios y aplicaciones web

Qué exige, en claro

Proteger los servicios y aplicaciones web frente a las amenazas propias del medio: las vulnerabilidades típicas (inyección, XSS, autenticación y control de accesos rotos, deserializaciones — el terreno OWASP), manipulación de URLs y parámetros, y abuso de sesiones (cookies seguras, expiración, anti-CSRF).

Con defensas verificables: cabeceras de seguridad, validación de entradas en servidor, TLS bien configurado (mp.com.3), un WAF donde aporte, y revisiones periódicas (análisis de vulnerabilidades o pentest según categoría) que confirmen que lo expuesto resiste. Enlaza con el desarrollo seguro (mp.sw.1) cuando la aplicación es propia.

Cuándo aplica y cómo escala

Aplica en cuanto el sistema expone servicios o aplicaciones web — hoy, prácticamente todo sistema. El rigor de las revisiones crece con la categoría. Confírmalo en la valoración formal del sistema.

Ejemplos de implementación

• Aplicación con validación en servidor, consultas parametrizadas, cookies Secure/HttpOnly/SameSite, anti-CSRF en todos los formularios y cabeceras de seguridad — verificado con un análisis externo periódico.
• WAF gestionado delante de los servicios públicos con reglas OWASP y bloqueo de los patrones de explotación más comunes, alimentando la detección (op.mon.1).

Errores habituales

• Validar solo en el navegador: el atacante no usa tu formulario, usa curl.
• Concatenar entradas del usuario en consultas SQL en pleno 2026.
• Sesiones eternas con cookies sin atributos de seguridad.
• Paneles de administración expuestos a todo Internet «porque tienen contraseña».
• No revisar nunca: la web que fue segura al estrenarse y nadie volvió a mirar.

Evidencias que suele ser razonable preparar

• Resultado reciente de análisis de vulnerabilidades o pentest sobre lo expuesto.
• Cabeceras de seguridad y configuración de sesiones verificables.
• WAF u otras protecciones perimetrales específicas de web, si existen.
• Prácticas de desarrollo seguro aplicadas (cuando la aplicación es propia, mp.sw.1).

Preguntas que debería hacerse el responsable

• ¿Cuándo se analizó por última vez tu web expuesta — y qué se encontró?
• ¿Qué cabeceras de seguridad devuelve tu aplicación ahora mismo?
• ¿El panel de administración es alcanzable desde cualquier IP del mundo?
• ¿Toda entrada del usuario se valida en el servidor?

Fuente oficial: Anexo II del Real Decreto 311/2022 y Guía CCN-STIC 812 · Seguridad de entornos web (CCN-CERT). Ficha elaborada por Roberto Mickel, fundador y CTO de ENSFácil; revisada el 25 de agosto de 2026: la aplicabilidad exacta y los refuerzos dependen de la categoría y valoración de tu sistema — verifica siempre la versión vigente de la norma y de las guías.