Por qué el modo Report-Only se diferencia del modo Enforced 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 ‘aplicación’ en Content Security Policy (CSP)…

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 ‘aplicación’ en Content Security Policy (CSP) no es un detalle menor: lo es todo. El modo solo informe te permite ver qué bloquearía tu política sin detener nada, y convierte tu sitio web en un auténtico campo de pruebas de seguridad. El modo de aplicación, en cambio, no se anda con rodeos: bloquea todo lo que contradiga tu política 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 una protección real. Está pensado para profesionales de seguridad y desarrolladores orientados a Microsoft que quieren configurar CSP correctamente, e incluye definiciones, técnicas prácticas y buenas prácticas para un despliegue seguro y un cumplimiento normativo inteligente.

Entender los modos de CSP y su impacto

Antes de empezar a añadir cabeceras CSP, conviene dominar los dos modos principales: solo informe y aplicación. No son simples opciones de configuración: 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 la fluidez del despliegue, especialmente 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 la entrada suave: te permite detectar problemas sin temor a romper algo para los usuarios. Ayuda a evaluar riesgos, a identificar huecos en la política y puede detectar código heredado o comportamientos inesperados de terceros, todo ello mientras tu aplicación sigue funcionando con normalidad.

El modo de aplicación es el plato fuerte: indica al navegador que ejecute realmente tus instrucciones. Si un contenido no cumple tu política, 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 políticas incompletas pueden interrumpir tu aplicación si no pruebas y adoptas los cambios con cuidado.

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

Cómo funciona Content-Security-Policy-Report-Only para el reporte de infracciones

El modo solo informe es la forma que tiene CSP de dejarte observar desde la grada antes de saltar a la pista. Cuando usas la cabecera HTTP Content-Security-Policy-Report-Only, le indicas al navegador que «vigile las infracciones, pero no bloquee nada, solo que las notifique». Así recibes un flujo de informes de infracciones enviados al endpoint que hayas especificado, con un resumen completo de lo que se bloquearía si la política estuviera en modo de aplicación.

Los navegadores envían estos informes de infracciones (normalmente como cargas útiles JSON) cada vez que un recurso incumple tus reglas de CSP. Por ejemplo, si una página intenta cargar un script desde un origen no aprobado, en modo solo informe ese script no se bloquea, pero sí recibes una alerta con detalles como la URL infractora, la directiva que se incumplió y, a veces, una muestra del código sospechoso.

Este modo es oro puro para las evaluaciones de riesgo y las pruebas seguras. Puedes desplegar nuevas reglas en un conjunto de aplicaciones web, ver qué se activa y ajustar la política con datos reales, no con simples 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 permite despliegues graduales. Empieza con una política abierta, observa qué necesita ajustes y avanza paso a paso hacia una seguridad más estricta. Permite detectar problemas con scripts de terceros, contenido de CDN o JavaScript ofuscado que, de otro modo, podrían quedar ocultos hasta que la aplicación provoque un fallo espectacular. Además, supone una ventaja de cumplimiento: demuestras que supervisas activamente, lo cual puede ayudar en las auditorías cuando tu organización necesita acreditar la debida diligencia.

Cómo el modo de aplicación 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 notablemente 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, podrías bloquear por accidente recursos necesarios y romper la funcionalidad del sitio. Lo más inteligente es probar primero en modo solo informe. En definitiva, el modo de aplicación es lo que convierte una política teórica en protección práctica, y es el estándar de oro para una seguridad web sólida.

Implementación de informes con los endpoints report-uri y report-to

Configurar los informes es lo que da a tu política CSP dientes reales y, además, un par de ojos. CSP te permite especificar uno o más endpoints (con report-uri o report-to) a los que los navegadores deben enviar los informes de infracciones. Cuando se produce una infracción, el navegador empaqueta detalles como el recurso bloqueado y la política que falló en un mensaje JSON o HTTP POST bien estructurado, y lo envía a tu endpoint.

La directiva report-uri es el método heredado: estableces una URL y los navegadores envían los informes directamente allí. 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 soporte de la Reporting API. report-to trabaja 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 podrían indicar un ataque o una política defectuosa). Y no olvides la privacidad: los informes pueden contener URL o incluso fragmentos del script infractor, por lo que debes estar preparado para depurar la información sensible antes de almacenarla o compartirla, teniendo presentes normativas como el RGPD y la CCPA.

El verdadero valor está en la visibilidad. Con informes bien configurados obtienes un flujo en tiempo real de dónde tu política detecta infracciones, lo que te permite 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.

Navegar por la sintaxis y las directivas de CSP para un diseño eficaz de la política

Escribir una cabecera CSP sólida no es ciencia de cohetes, pero sí exige 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, cada una de las cuales 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 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 el valor de reserva: si un tipo de contenido concreto no tiene su propia regla, el navegador consulta esta. script-src e img-src se centran en scripts e imágenes, y te permiten controlar con precisión los orígenes de confianza (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 necesarios para código heredado), podrías necesitar 'unsafe-inline', pero ten cuidado: esto debilita tu protección a menos que utilices hashes o nonces de script para una validación adicional.

Para 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 tiene que equilibrar el rigor (por seguridad) con la flexibilidad suficiente para que la aplicación funcione. Si defines bien lo básico desde el principio, las pruebas serán mucho más fluidas más adelante.

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

Lo más inteligente con CSP es empezar en modo solo informe, recopilar datos y, solo entonces, activar la aplicación. No trates la implantación de CSP como una lista de comprobación de una sola vez. Enfócala como un proyecto por fases, en el que vas monitorizando, ajustando y endureciendo gradualmente las políticas para evitar romper la funcionalidad de los usuarios finales o los flujos de trabajo críticos para el negocio.

Empieza con una directiva amplia pero sensata en modo solo informe. Recopila los informes de infracciones; lo ideal es agregarlos mediante paneles o herramientas de análisis para destacar 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 (lo cual es habitual), ajusta tu análisis de registros o incluso crea filtros con scripts 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 y sigue vigilando la aparición de nuevas incidencias. 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 política 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 complicaciones. Para estrategias relacionadas y planes de despliegue, merece la pena consultar esta guía sobre problemas de confianza en el acceso condicional y este episodio sobre seguridad de identidad.

Nunca subestimes 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 blindada, conforme y resistente, protegida por una directiva que se ha depurado en el mundo real y no con buenas intenciones.

Ejemplos reales de CSP en modo solo informe y en modo aplicado

Nada explica mejor CSP que los ejemplos reales. En modo solo informe, podrías usar una cabecera como: 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, por lo que es ideal para probar en producción sin riesgos.

Frente a esto, 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 de forma activa 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 solo informe para detectar qué proveedores, scripts o funciones de negocio fallarían con un bloqueo total simulado. 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 política final por fases para minimizar las interrupciones.

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

Resumen de las diferencias clave entre los modos solo informe y aplicado

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