Cómo activar una Content Security Policy sin romper el checkout de tu e-commerce

Una Content Security Policy, o CSP, ayuda a definir qué recursos puede cargar o ejecutar el navegador al visitar una página. Para una empresa, el reto no suele ser entender su finalidad, sino aplicarla sin interrumpir un pago, un formulario, la analítica, el chat o cualquier integración que sostenga la operación diaria. Una política aplicada de forma brusca puede convertir una medida defensiva en una incidencia comercial.

La forma prudente de implantar una CSP es tratarla como un proceso de control de dependencias: saber qué servicio carga cada recurso, por qué se necesita, quién lo aprueba y en qué páginas debe funcionar. Este enfoque permite avanzar por fases, empezar por recorridos críticos y reducir autorizaciones innecesarias sin asumir que una configuración genérica servirá para todas las webs.

El problema: dependencias invisibles en páginas críticas

En una web corporativa o tienda online, el navegador puede cargar scripts, imágenes, conexiones y marcos desde numerosos proveedores. Algunos responden a necesidades claras, como una pasarela de pago o un mapa; otros pueden proceder de un plugin antiguo, una etiqueta de campaña temporal o una herramienta que nadie revisa desde hace tiempo. El problema concreto es perder visibilidad sobre esas dependencias y autorizar más de lo necesario por miedo a que algo deje de funcionar.

La cabecera HTTP Content-Security-Policy permite indicar de qué fuentes puede cargar o ejecutar recursos una página. Puede contribuir a mitigar determinados ataques de inyección de contenido y XSS, pero necesita adaptarse a cada sitio y a sus integraciones reales. Por tanto, no conviene empezar pegando una política encontrada en otra web: el punto de partida debe ser el comportamiento autorizado de la propia aplicación. [2]

• Priorice inicio de sesión, área de cliente, formularios, carrito y checkout.
• Registre cada tercero con su dominio, función, páginas afectadas y responsable interno.
• Incluya conexiones con CRM, ERP u otras APIs usadas desde el navegador.

Qué cubre una CSP y cuáles son sus límites

Una CSP actúa en el navegador renderizando HTML: puede limitar, entre otros elementos, los scripts que se ejecutan, las conexiones salientes, las imágenes, los formularios y los sitios que pueden incrustar una página. Directivas como script-src, connect-src, img-src, form-action, base-uri y frame-ancestors deben responder a una necesidad concreta, no a una receta universal. [2] [3]

No sustituye la corrección de vulnerabilidades, la validación de entradas, la codificación de salida ni la revisión del código. OWASP sitúa la CSP como una defensa adicional frente a XSS, no como reemplazo de las medidas principales. Tampoco hace seguro a un proveedor externo solo por incluir su dominio en una lista permitida; cada autorización sigue siendo una decisión de riesgo y operación. [1]

• Evite aprobar dominios con comodines o “por si acaso”.
• No normalice unsafe-inline o unsafe-eval como solución permanente.
• Cuando la arquitectura lo permita, valore nonces por respuesta o hashes para autorizar scripts concretos.

Primero inventariar y observar, después bloquear

Antes de imponer restricciones, prepare un inventario por plantilla o recorrido de negocio. Distinga, por ejemplo, la página de producto, el acceso a cuenta y el checkout. Una pasarela puede requerir recursos que no aparecen en el resto de la web, y una política separada para esa zona puede ser más manejable que una excepción amplia aplicada a todo el dominio. Haga las pruebas solo en entornos y sistemas para los que exista autorización expresa.

El modo Content-Security-Policy-Report-Only permite recibir avisos de incumplimiento sin bloquear todavía los recursos. Es útil para identificar dependencias durante una ventana que cubra el uso real: campañas activas, pagos, registros, formularios y distintos dispositivos. Los avisos no son una lista automática de dominios que deban aprobarse; son material para investigar, clasificar y decidir. [4]

• Asigne un responsable a la revisión de cada incumplimiento.
• Diferencie recursos legítimos, dependencias obsoletas y comportamientos desconocidos.
• Conserve una política validada a la que volver mediante un procedimiento de reversión autorizado.

Definir reglas mínimas y proteger los reportes

Tras revisar los avisos, permita únicamente los orígenes necesarios para cada función. script-src regula scripts; connect-src, las conexiones iniciadas por el navegador; img-src, las imágenes; y form-action, los destinos permitidos para el envío de formularios. frame-ancestors merece una comprobación específica: controla qué sitios pueden mostrar la página en un iframe, por lo que antes hay que confirmar si existen portales, soporte u otras incrustaciones legítimas. [2]

Los reportes de CSP también requieren controles. Pueden contener datos no confiables, por lo que deben validarse y sanearse antes de almacenarlos, mostrarlos en un panel o emplearlos en automatizaciones. Evite que un informe genere por sí mismo una excepción en la política: toda modificación necesita revisión humana, un propietario y una justificación técnica y operativa. [5]

• Documente el motivo y la fecha de cada origen aprobado.
• Pruebe el pago completo, recuperación de contraseña, envío de formularios y confirmaciones.
• Si un tercero cambia sus dominios o recursos, vuelva a evaluar la necesidad antes de ampliar permisos.

Paso a producción y mantenimiento continuo

El paso a modo de aplicación debe hacerse gradualmente y con verificación funcional. En un ejemplo hipotético, una tienda puede activar primero la política en la zona de cuenta, confirmar que el acceso y la recuperación de contraseña funcionan, y después incorporar el checkout tras probar el flujo de pago con la pasarela autorizada. Si surge un bloqueo crítico, aplique la reversión documentada, registre qué ocurrió y corrija la regla o la dependencia antes de reintentar.

La CSP debe integrarse en el proceso de cambio web. Un nuevo plugin, píxel publicitario, chat, proveedor de pago o automatización puede requerir recursos adicionales y debe pasar por revisión antes de publicarse. Una auditoría de protección web puede ayudar a ordenar este inventario, revisar configuraciones y validar recorridos autorizados; no elimina la responsabilidad de mantener la política alineada con la arquitectura y el negocio.

• Incluya la revisión de CSP en altas de proveedores y despliegues.
• Retire permisos cuando se elimine una integración.
• Revise periódicamente las páginas críticas y los cambios de terceros.

Preguntas frecuentes

¿Una Content Security Policy evita todos los ataques XSS?

No. Puede reducir el impacto de determinados escenarios de inyección y XSS al limitar recursos que el navegador acepta, pero es una capa complementaria. La aplicación debe seguir aplicando validación de entradas, codificación de salida, sanitización cuando corresponda y revisión de código.

¿Debo usar la misma CSP en toda la web?

No necesariamente. Las páginas pueden tener dependencias diferentes. El checkout, por ejemplo, puede necesitar recursos de una pasarela que no deben autorizarse en una página informativa. La decisión depende de la arquitectura y debe probarse en recorridos autorizados y representativos.

¿Qué hago si el modo Report-Only genera muchos avisos?

Clasifíquelos antes de cambiar la política. Identifique la página afectada, el recurso, su proveedor, su función y su responsable interno. Apruebe solo lo necesario, retire dependencias antiguas cuando sea viable y trate los datos de los reportes como no confiables antes de visualizarlos o automatizar acciones con ellos.