Cómo introducir una política CSP sin enterarte de las páginas rotas por los lectores

Empieza a desplegar Content Security Policy con observación y un conjunto representativo de páginas. Una política copiada puede hacer que la portada parezca segura mientras rompe el contenido multimedia, un pago o la vista previa del editor. El objetivo es restringir la ejecución no deseada y mantener las funciones que la publicación realmente quiere ofrecer.

La especificación CSP distingue una política aplicada de Content-Security-Policy-Report-Only, que permite al navegador supervisar una propuesta sin imponerla. Report-only ayuda a conocer sus efectos. No proporciona la protección de esa propuesta aplicada ni desactiva otra política que ya esté en vigor.

Mapea el sitio que realmente operas

Enumera tipos de página y recorridos representativos antes de escribir reglas. Incluye un artículo normal, una página multimedia, búsqueda, ediciones traducidas y las funciones comerciales reales. No añadas servicios imaginarios al inventario. Una publicación estática sin cuentas, seguimiento ni scripts de pago tiene dependencias distintas de un negocio de membresías.

Para cada recorrido, identifica scripts, estilos, imágenes, fuentes, marcos y conexiones necesarios. Anota el responsable y la finalidad de cada dependencia externa. Un dominio observado en el navegador es una pista, no un permiso automático para confiar en todo lo que sirve. Pregunta si la función pertenece a la página antes de añadir una excepción para mantenerla.

Inspecciona las cabeceras de respuesta y la ruta de entrega reales. La política puede añadirse en el origen, en el alojamiento o en una capa de distribución. Si varios lugares aportan cabeceras, determina qué configuración manda antes de editar. De lo contrario, alguien puede cambiar un ajuste local mientras el público sigue recibiendo una política distinta.

Entrega la propuesta como cabecera report-only

La especificación señala que la política report-only no se admite dentro de un elemento meta. Configura la cabecera HTTP mediante el proceso de despliegue compatible con el sitio. Mantén visible la política aplicada actual para interpretar bien la prueba: observar una propuesta adicional no demuestra que se hayan retirado todas las restricciones existentes.

Elige un mecanismo de informes compatible y confirma que el endpoint receptor acepta los informes esperados. La referencia de cabecera de MDN explica la entrega y la configuración de informes. Escribir una directiva no crea el servicio que recibe, almacena y revisa los datos.

Limita el primer experimento para poder entenderlo. Utiliza un entorno controlado o un despliegue reducido adecuado a la publicación, y conserva la configuración anterior. Prueba la consola del navegador y la vía de recogida. Si no llegan informes, comprueba primero que la recopilación funciona antes de concluir que no hay infracciones.

Trata los informes recibidos como entradas no fiables. Reduce la conservación innecesaria, protege el acceso al receptor y evita compartir direcciones sensibles en canales amplios de incidencias. Un informe puede contener información operativa del contexto de la página visitada. Revisa qué recoge la configuración antes de contratar un servicio externo, sin tratarlo como una tubería neutral.

Convierte los informes en decisiones, no en una lista creciente de permisos

Agrupa los hallazgos por tipo de página, directiva y recurso. Reproduce fallos representativos mediante los recorridos previstos. Una extensión o un estado inusual del navegador pueden generar ruido, por lo que un informe debe iniciar una investigación, no autorizar automáticamente una fuente nueva. También descartar cada entrada extraña como ruido puede ocultar un problema real.

Para cada dependencia legítima, decide si mantenerla, sustituirla o retirarla. Una lista creciente de excepciones amplias puede conservar scripts antiguos y debilitar el propósito de la política. La guía CSP de OWASP aporta contexto, incluidos enfoques más sólidos con nonces o hashes. Necesitan generación y entrega correctas, no un valor fijo de ejemplo reutilizado.

Presta especial atención a vistas previas, traducciones y caché si utilizas nonces. La cabecera y el marcado permitido deben corresponder al mismo mecanismo de respuesta. Usa la revisión de reglas de caché cuando una capa de distribución cambie lo que recibe cada lector. Una visita de desarrollo sin caché no representa necesariamente la página pública almacenada.

Aplica la política en un cambio controlado y sigue observando

Define criterios de aceptación mediante funciones, no solo con informes silenciosos. ¿Se abren los artículos, funciona el contenido multimedia previsto y se completan los pagos reales? ¿Pueden los editores previsualizar? ¿Se han comprobado idiomas, tamaños de pantalla y estados de consentimiento relevantes? La recopilación puede ser incompleta, por lo que la ausencia de infracciones registradas no prueba que se hayan recorrido todas las rutas.

Antes de activar, registra la versión, los casos probados, las limitaciones y el procedimiento exacto de reversión. Utiliza un proceso de pruebas y vuelta atrás. Modifica la política aplicada mediante la publicación habitual y verifica las cabeceras entregadas y los mismos recorridos en el resultado activo. Mantén disponible a un responsable durante la primera observación.

Comprueba los errores junto con pruebas funcionales después del cambio. Si falla una función legítima crítica, restaura una configuración conocida o realiza una corrección limitada y comprendida. Evita permitir todas las fuentes para silenciar alertas. La reparación debe poder relacionarse con la dependencia y el comportamiento que la exigieron.

Mantén el inventario y la revisión de la política en futuras versiones. Al retirar un proveedor, elimina los permisos que ya no necesita; al añadir una función, vuelve a comprobar compatibilidad. CSP funciona mejor como parte mantenida de la entrega, junto con seguridad de la aplicación y control de acceso, no como una insignia obtenida una vez al añadir una cabecera.