Content Security Policy parece complicada porque controla una frontera real: qué recursos puede cargar una página y desde qué orígenes. Copiar una política enorme de internet suele crear una segunda clase de problemas: la web funciona en desarrollo y deja de funcionar en producción.
Qué intenta proteger
CSP reduce el impacto de ciertos ataques de inyección restringiendo scripts, imágenes, estilos, fuentes, frames y conexiones. No sustituye a la validación del servidor ni a una arquitectura segura, pero añade una capa importante.
Empieza por inventariar
Antes de escribir directivas, identifica los recursos reales: JavaScript propio, proveedores de analítica, vídeo, imágenes externas, fuentes, APIs, CAPTCHA e iframes. La política debería describir lo que utiliza la web, no lo que imaginas que utiliza.
Scripts
script-src suele ser la parte más sensible. Una política demasiado abierta elimina parte del valor de CSP. Una demasiado estricta rompe librerías, widgets o integraciones legítimas. Los nonces y hashes pueden ser útiles cuando el diseño lo permite.
Iframes y multimedia
frame-src, img-src, media-src y connect-src deben revisarse por separado. Un vídeo bloqueado no implica que el reproductor esté mal: puede ser el navegador rechazando un origen que la política no contempla.
Investigar un bloqueo
Cuando una función falla en producción, abre DevTools y busca mensajes de CSP. Después revisa Network para saber qué petición se intentó hacer y cuál fue su origen. Corrige la política con la mínima apertura necesaria.
No uses CSP como botón mágico
Una política no corrige un secreto expuesto, un endpoint inseguro ni una autorización incorrecta. Es una capa complementaria.
Despliegue gradual
Una práctica útil es observar violaciones antes de aplicar una política estricta. Con suficiente información se puede eliminar dependencias innecesarias y diseñar una política que refleje realmente la arquitectura.
Conclusión
CSP funciona mejor cuando se trata como parte del producto y del despliegue. Documenta qué proveedores son necesarios, revisa la política cuando cambie una integración y prueba las rutas multimedia, analítica y autenticación en producción.
Diseñar una CSP que se pueda mantener
Content Security Policy funciona mejor cuando nace de los recursos que la aplicación necesita y no de una lista copiada de internet. Antes de escribir directivas, identifica scripts, imágenes, estilos, fuentes, frames y conexiones que realmente utiliza la página.
Empieza con lo que ya existe
Utiliza las herramientas del navegador para observar qué recursos se cargan. Agrupa por tipo y dominio. Esta fotografía inicial evita conceder permisos a proveedores que la aplicación ya no utiliza.
Scripts
script-src merece especial atención porque controla una superficie muy sensible. Cuanto más amplia sea la política, menos útil será como defensa. Es preferible reducir dominios y utilizar mecanismos adecuados para scripts propios cuando la arquitectura lo permita.
Frames y vídeo
Un iframe permitido por el navegador depende de la directiva adecuada. No todas las políticas que mencionan frames responden a la misma pregunta. Distinguir carga del recurso de quién puede incrustar la página evita errores de configuración.
Conexiones de API
connect-src afecta solicitudes realizadas desde el navegador. Si una aplicación utiliza Supabase, analítica o una API externa, esas conexiones deben estar contempladas explícitamente.
Investigar un bloqueo CSP
Cuando el navegador muestra un error de política, copia la directiva y el origen bloqueado. No cambies toda la CSP. Añade únicamente la autorización que corresponde al recurso legítimo, vuelve a probar y observa si aparece un segundo bloqueo relacionado.
CSP como inventario
Una ventaja poco visible de una política estricta es que obliga a conocer los proveedores que la aplicación realmente necesita. El mantenimiento mejora cuando cada dominio externo tiene una razón concreta.
CORS no es CSP
CORS decide si una página puede leer determinadas respuestas de otro origen desde el navegador. CSP decide qué recursos y conexiones están permitidos por la política de seguridad de la página. Pueden aparecer a la vez, pero no son intercambiables.
Una estrategia progresiva
Primero mide. Después documenta. Luego restringe. Finalmente vuelve a medir. La seguridad mejora cuando cada cambio puede relacionarse con un recurso concreto y una prueba concreta.
Cierre FMCP
Una buena CSP no es una muralla que bloquea todo. Es una lista mantenible de lo que la aplicación necesita, con el mínimo de confianza necesario. Su calidad se demuestra tanto cuando una integración funciona como cuando un recurso inesperado es rechazado.
CSP como contrato de dependencias
Una política de seguridad también puede funcionar como inventario. Cuando un proveedor deja de utilizarse, su dominio debería poder retirarse. Cuando aparece una dependencia nueva, debería quedar claro por qué necesita acceso y a qué directiva pertenece.
Evita excepciones permanentes
Una excepción creada para depurar puede terminar olvidada durante años. Documenta cualquier ampliación temporal y vuelve a revisar si sigue siendo necesaria después del lanzamiento.
Prueba la política en condiciones reales
Comprueba la página autenticada, la pública, el administrador y las rutas que cargan multimedia. Una CSP correcta para una página puede no cubrir otra que utilice recursos diferentes.
Cierre ampliado
Una CSP madura no es estática. Evoluciona con la aplicación, pero cada cambio debe tener una razón observable. Esa disciplina mantiene la seguridad útil sin convertirla en una fuente constante de bloqueos inexplicables.
CSP sin miedo: diseñar la política alrededor de las dependencias reales
Content Security Policy funciona mejor cuando deja de tratarse como una cadena que se copia de un ejemplo y pasa a representar las necesidades reales de la aplicación. Una política demasiado permisiva pierde valor; una política demasiado estricta rompe scripts, imágenes o integraciones legítimas.
Empieza por inventariar fuentes
Antes de escribir script-src, identifica qué scripts existen realmente: código propio, analítica, CAPTCHA, reproductores, pagos, mapas y otras integraciones. Lo mismo debe hacerse con imágenes, fuentes, conexiones y frames. La política debe salir del inventario, no al revés.
Qué protege y qué no
CSP reduce determinadas clases de ejecución no autorizada, especialmente cuando una entrada consigue llegar a HTML o scripts en el navegador. No sustituye la validación de entradas, el escaping, una arquitectura segura ni la autorización del servidor.
Reportar antes de bloquear
En una aplicación activa es razonable desplegar primero una política de observación para detectar recursos que aún no se han contemplado. Después se corrigen dependencias y se pasa gradualmente a enforcement. Este enfoque reduce la probabilidad de romper producción sin sacrificar el objetivo final.
Evitar comodines innecesarios
Permitir cualquier dominio de una categoría entera puede anular parte del beneficio de la política. Es mejor autorizar orígenes concretos y revisarlos cuando una integración cambie. También conviene prestar especial atención a frame-src, connect-src y img-src, porque suelen crecer con el tiempo.
La política como contrato técnico
Cuando una aplicación incorpora un servicio nuevo, la CSP debería formar parte de la lista de cambios. Así se evita el patrón de añadir https: o * cada vez que aparece una incompatibilidad.
Diagnóstico de una violación
Un bloqueo de CSP debe responder a una pregunta sencilla: ¿era un recurso legítimo o una ejecución inesperada? Los informes son más útiles cuando incluyen suficiente contexto para identificar el origen sin almacenar información sensible innecesaria.
La CSP bien diseñada no pretende que la web deje de funcionar. Pretende que el navegador tenga una lista explícita de lo que la aplicación está autorizada a cargar o ejecutar.
CSP como proceso continuo
Una política de seguridad web no queda terminada para siempre. Cada nueva dependencia puede introducir un origen adicional, cada cambio de infraestructura puede alterar conexiones y cada integración externa puede necesitar un ajuste controlado.
Versionar la política
La CSP debería revisarse junto al código. Una política almacenada como configuración versionada permite saber por qué apareció un dominio y quién lo aprobó.
Probar primero
Las violaciones de política son información. Úsalas para descubrir recursos inesperados antes de bloquear. Cuando la lista de dependencias es estable, pasa progresivamente a una política de enforcement estricta.
Evitar soluciones globales
Añadir * porque una integración no funciona es cómodo a corto plazo y caro a largo plazo. Es preferible entender exactamente qué recurso necesita permiso y abrir solo ese origen.
Una CSP útil también protege la experiencia
El objetivo no es bloquear tanto como sea posible. Una política útil permite exactamente los recursos que la aplicación necesita y documenta por qué los necesita. Cada excepción debería tener una razón de negocio o técnica.
Integraciones habituales
Analítica, CAPTCHA, pagos, vídeos y APIs externas son fuentes frecuentes de violaciones legítimas. La solución no es abrir todos los dominios, sino identificar cada dependencia y limitarla a los orígenes necesarios.
Mantener la política pequeña
Cuanto más larga sea la lista, más difícil es auditarla. Revisa periódicamente dominios que ya no se utilizan y elimina permisos antiguos. La reducción de superficie es una mejora continua, no un cambio único.
Probar la política con cambios reales
La validación final de CSP debe incluir navegación real por todas las áreas importantes de la aplicación. Una política perfecta sobre papel no sirve si rompe el login, el reproductor o un formulario crítico. El objetivo es seguridad y disponibilidad al mismo tiempo.
Una CSP pequeña es más fácil de entender y mantener
Cada permiso adicional aumenta la superficie que hay que revisar. El objetivo no es construir una política espectacularmente larga, sino una política que un desarrollador pueda explicar meses después: qué servicio necesita cada origen y por qué.
La revisión periódica debe retirar excepciones que ya no tengan una función.
