Por qué el modo solo informe difiere del modo aplicado en Content Security Policy

By Mirko Peters · 2026-04-23

Si te tomas en serio la seguridad web, entender la diferencia entre los modos "solo informe" y "aplicado" en Content Security Policy…

Automatically translated with AI from the original post. Read the English original

Si te tomas en serio la seguridad web, entender la diferencia entre los modos "solo informe" y "aplicado" en Content Security Policy (CSP) no es un simple detalle: es lo que lo decide todo. El modo solo informe te permite ver qué bloquearía tu directiva sin detener nada, convirtiendo tu sitio web en una especie de campo de pruebas de seguridad. El modo aplicado, en cambio, no anda con rodeos: bloquea todo lo que vaya en contra de tu directiva y blinda tu sitio en tiempo real.

Este artículo explica por qué importan estos modos, qué efecto tienen en el navegador y en la experiencia del usuario, y cómo pasar de la simple monitorización a la protección real. Está pensado específicamente para profesionales de seguridad y desarrolladores centrados en Microsoft que quieren configurar bien su CSP, e incluye definiciones, técnicas prácticas y buenas prácticas para un despliegue seguro y un cumplimiento normativo inteligente.

Comprender los modos de CSP y su impacto

Antes de empezar a añadir cabeceras CSP, tienes que entender los dos modos principales de CSP: solo informe y aplicado. No son simples ajustes: determinan cómo los navegadores modernos protegen (o simplemente observan) los límites de seguridad de tu aplicación web. Lo que elijas afecta directamente al nivel de riesgo de tu sitio, a tu capacidad de auditoría y a lo fluido que sea el despliegue, sobre todo en entornos grandes de Microsoft o en configuraciones multicloud.

Los modos de CSP se diseñaron para dar flexibilidad a los equipos web. El modo solo informe es el punto de entrada suave: te permite vigilar posibles problemas sin miedo a romper algo para los usuarios. Ayuda a evaluar riesgos, a detectar huecos en la directiva y puede identificar código heredado o comportamientos inesperados de terceros, todo ello manteniendo tu aplicación completamente operativa.

El modo aplicado es el plato fuerte: indica al navegador que cumpla de verdad tus instrucciones. Si un contenido no coincide con tu directiva, se bloquea de inmediato, lo que reduce la superficie de ataque frente a amenazas como el cross-site scripting o los scripts maliciosos de terceros. Pero también significa que los errores o las directivas incompletas pueden interrumpir tu aplicación si no tienes cuidado con las pruebas y la adopción.

La idea detrás de tener ambos modos es sencilla: dejar que desarrolladores y equipos de seguridad afinen sus reglas en entornos reales antes de apretar el gatillo. Piénsalo como las ruedas de apoyo para la seguridad de tu aplicación, pero con una meta clara: el momento en que pasas a la aplicación completa. A continuación veremos cómo el modo solo informe te da esa retroalimentación del mundo real y qué cambia cuando entra en juego el modo aplicado.

Cómo funciona Content-Security-Policy-Report-Only para la notificación de infracciones

El modo solo informe es la forma que tiene CSP de dejarte observar desde la grada antes de saltar a la pista. Al usar la cabecera HTTP Content-Security-Policy-Report-Only, indicas al navegador que "vigile las infracciones, pero no bloquee nada, solo notifícalas". Así recibes un flujo de informes de infracción enviados al endpoint que hayas especificado, con un resumen completo de lo que se bloquearía si la directiva estuviera aplicada.

Los navegadores enviarán estos informes de infracción (normalmente como cargas JSON) cada vez que un recurso incumpla tus reglas de CSP. Por ejemplo, si una página intenta cargar un script desde un origen no aprobado, en el modo solo informe no se bloquea ningún script, pero recibirás una alerta con detalles como la URL infractora, la directiva que se ha vulnerado y, a veces, una muestra del código sospechoso.

Este modo es oro puro para evaluaciones de riesgo y pruebas seguras. Puedes desplegar nuevas reglas en un conjunto de aplicaciones web, ver qué se activa y ajustar la directiva según datos reales, no solo según suposiciones. Si tienes sistemas heredados o flujos de trabajo empresariales críticos, no arriesgarás caídas del sitio ni llamadas de soporte por avanzar demasiado rápido.

El modo solo informe también facilita los despliegues graduales. Empieza sin restricciones, mira qué necesita ajustes y avanza paso a paso hacia una seguridad más estricta. Permite descubrir problemas con scripts de terceros, contenido de CDN o JavaScript ofuscado que, de otro modo, podrían permanecer ocultos hasta que el modo aplicado provoque un fallo espectacular. Además, es una ventaja para el cumplimiento: tienes pruebas de que monitorizas activamente, lo que puede ayudarte en las auditorías cuando tu organización necesite demostrar la diligencia debida.

Cómo el modo aplicado aumenta la seguridad

El modo de aplicación (enforced) es el momento en que tu política CSP deja de ser una sugerencia y se convierte en una regla. Cuando usas la cabecera Content-Security-Policy, los navegadores bloquean de verdad cualquier contenido que no cumpla tus directivas: sin advertencias, solo acción.

Este modo refuerza de forma notable tu aplicación web frente a ataques como XSS y la inyección no autorizada de scripts. Pero ten cuidado: si tu política no está lista para producción, puedes bloquear sin querer recursos necesarios y romper la funcionalidad del sitio. Probar primero en modo solo informe es la decisión inteligente. En definitiva, el modo de aplicación es lo que convierte una política teórica en protección práctica, y por eso es el estándar de referencia para una seguridad web sólida.

Implementar la notificación con los endpoints report-uri y report-to

Configurar los informes es el punto en que tu política CSP gana dientes de verdad, y también un par de ojos. CSP te permite especificar uno o varios endpoints (mediante report-uri o report-to) a los que los navegadores deben enviar los informes de infracción. Cuando se produce una infracción, el navegador empaqueta los detalles, como el recurso que se bloqueó y la política que falló, en un mensaje JSON o HTTP POST y lo envía a tu endpoint.

La directiva report-uri es el método heredado: indicas una URL y los navegadores envían allí los informes directamente. Sin embargo, para una mayor flexibilidad moderna y unos informes más completos, report-to es la opción más nueva y robusta, sobre todo a medida que los navegadores amplían su compatibilidad con la Reporting API. report-to funciona con un grupo con nombre que puede gestionar distintos tipos de informes y ofrece un mejor control de filtrado.

Al configurar estos endpoints, conviene protegerlos: usa HTTPS, controles de acceso y monitorización de picos inesperados (que pueden indicar un ataque o una política mal configurada). Y no olvides la privacidad: los informes pueden contener URLs o incluso fragmentos del script infractor, así que debes estar preparado para eliminar la información sensible antes de almacenarla o compartirla, teniendo en cuenta normativas como el RGPD y la CCPA.

El verdadero valor está en la visibilidad. Con una notificación bien configurada, obtienes un flujo en tiempo real de dónde tu política detecta infracciones, para que puedas ajustar, afinar y, finalmente, pasar a la aplicación sin sorpresas. Este nivel de monitorización es esencial, tanto si gestionas una sola aplicación como un entorno de Microsoft 365 extenso.

Cómo navegar por la sintaxis y las directivas de CSP para diseñar una política eficaz

Escribir una cabecera CSP sólida no es ciencia de cohetes, pero sí requiere atención al detalle, sobre todo cuando se combinan aplicaciones complejas con integraciones en la nube de Microsoft. En la base, una política CSP es una lista estructurada de directivas, y cada una indica a los navegadores qué está permitido y qué no. Estas políticas se envían mediante cabeceras HTTP, normalmente como Content-Security-Policy o Content-Security-Policy-Report-Only, con el formato de cadenas de reglas separadas por punto y coma.

El núcleo de tu política está en directivas clave como default-src, script-src e img-src. default-src es tu valor de respaldo: si un tipo de contenido no tiene su propia regla, el navegador consulta esta. script-src e img-src se centran en los scripts y las imágenes, lo que te permite controlar con precisión los orígenes de confianza (piensa en tus dominios, CDN de confianza y, quizá, algún blob de Microsoft Azure).

La sintaxis importa. Cada directiva enumera los valores permitidos: URL, esquemas como 'https:' o palabras clave como 'self'. Si permites scripts en línea (a veces necesario para código heredado), puede que necesites 'unsafe-inline', pero ten cuidado: esto debilita tu protección a menos que uses hashes o nonces de script para una validación adicional.

En el caso de los profesionales de Microsoft, presta atención a cómo los servicios en la nube inyectan dependencias. Las aplicaciones empresariales complejas suelen cargar recursos de forma dinámica, usar service workers o integrar proveedores de terceros. Tu política debe equilibrar la restricción (por seguridad) con la flexibilidad suficiente para que la aplicación funcione. Si haces bien lo básico desde el principio, las pruebas serán mucho más sencillas más adelante.

Buenas prácticas para pasar del modo solo informe al modo de aplicación

La decisión más inteligente con CSP es empezar en modo solo informe, recopilar datos y solo entonces activar la aplicación. No trates el despliegue de CSP como una lista de comprobación de una sola vez. Enfócalo como un proyecto por fases, en el que monitorizas, ajustas y endureces gradualmente las políticas para no interrumpir la funcionalidad de los usuarios finales ni los flujos de trabajo críticos para el negocio.

Empieza con una directiva amplia pero razonable en modo de solo informe. Recopila los informes de infracciones; lo ideal es agregarlos con paneles o herramientas de análisis para detectar a los infractores recurrentes. Así podrás separar el ruido, filtrar los falsos positivos y centrarte en los riesgos reales. Si encuentras muchos informes rutinarios o redundantes (algo habitual), ajusta tu análisis de registros o incluso crea scripts de filtrado por user agent o tipo de recurso.

Cuando el volumen de infracciones baje y la mayoría de los problemas estén resueltos, empieza a aplicar las reglas de forma gradual, sin dejar de vigilar la aparición de nuevas roturas. Pasa primero a modo de aplicación las secciones de alto riesgo y bajo tráfico, y supervísalas. Si todo va bien, extiende la directiva al resto del proyecto. Documenta los cambios y recoge los comentarios de desarrolladores y partes interesadas durante todo el proceso, sobre todo en aplicaciones complejas de Microsoft 365 o Azure, donde las capas de acceso condicional añaden más complicaciones. Para estrategias y planes de implantación relacionados, merece la pena revisar esta guía sobre los problemas de confianza en las directivas de acceso condicional y este episodio sobre seguridad de identidades.

No subestimes nunca las pruebas. Usa las herramientas de desarrollo del navegador, los comprobadores de estado de CSP e incluso análisis automatizados en CI/CD para confirmar que tus directivas funcionan como esperas. ¿El objetivo final? Una aplicación bien protegida, conforme con la normativa y resistente, respaldada por una directiva que se ha depurado en entornos reales y no por buenas intenciones.

Ejemplos reales de CSP en modo de solo informe y en modo de aplicación

Nada da vida a CSP como los ejemplos reales. En modo de solo informe, podrías usar un encabezado como este: Content-Security-Policy-Report-Only: default-src 'self'; report-uri https://csp-report.example.com. Esta configuración registra cada infracción sin afectar a los usuarios, lo que la hace ideal para probar en producción sin riesgos.

Frente a ello, una directiva aplicada: Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com; img-src 'self'; report-uri https://csp-report.example.com. Ahora el navegador bloquea activamente cualquier script o imagen que no cumpla las reglas, protegiendo a los usuarios de contenido no aprobado desde el primer momento.

En la práctica, las organizaciones empiezan en modo de solo informe para detectar qué proveedores, scripts o funcionalidades de negocio se romperían con un bloqueo total. Por ejemplo, un portal web gubernamental podría descubrir scripts heredados o una CDN de analítica de marketing que genera infracciones repetidas. Iteran, incluyen en la lista de permitidos a los proveedores seguros y, después, aplican la directiva final por fases para minimizar las interrupciones.

Pasar de solo informe a aplicación puede revelar minas ocultas, sobre todo con scripts de terceros o contenido dinámico. Los equipos suelen encontrarse con infracciones «fantasma» que solo aparecen en ciertos navegadores o bajo condiciones específicas. Con los datos reales de la fase de solo informe, ajustan la directiva hasta que la aplicación no solo sea segura, sino también estable para todos los implicados.

Resumen de las diferencias clave entre el modo de solo informe y el modo de aplicación

• Comportamiento: el modo de solo informe únicamente notifica las infracciones de la directiva; no bloquea ningún contenido. El modo de aplicación bloquea activamente todo lo que incumpla tu directiva CSP.
• Finalidad: el modo de solo informe permite probar y ajustar las directivas sin ningún riesgo para los usuarios. El modo de aplicación sirve para la protección real, haciendo efectivas las reglas de seguridad.
• Impacto en los usuarios: el modo de solo informe es invisible; los usuarios nunca lo notan. El modo de aplicación puede romper funciones o contenido si no has probado antes tus reglas.
• Casos de uso: el modo de solo informe es ideal para implantaciones graduales, análisis de riesgos y comprobaciones de compatibilidad con sistemas heredados. El modo de aplicación es el paso final para lograr una seguridad sólida y conforme con la normativa.
• Cumplimiento y riesgo: el modo de solo informe ayuda con la supervisión y la documentación durante las auditorías, mientras que el modo de aplicación previene directamente las brechas de seguridad en tiempo real.