CSP para Pentesters: Fundamentos de Content-Security-Policy

¿Qué es Content-Security-Policy y por qué importa a tu startup?

Si estás construyendo un SaaS o producto tech, la seguridad web no es opcional. Content-Security-Policy (CSP) es uno de los mecanismos de defensa más efectivos contra ataques de Cross-Site Scripting (XSS), una vulnerabilidad que puede comprometer datos de usuarios y destruir la confianza en tu producto.

CSP funciona como una lista blanca que le dice al navegador qué recursos puede ejecutar o cargar tu aplicación. En lugar de confiar ciegamente en todo el código que llega al navegador, defines políticas específicas mediante cabeceras HTTP que restringen el origen de scripts, estilos, imágenes y otros recursos.

Para founders tech que escalan productos, implementar CSP temprano puede ser la diferencia entre un incidente menor y una brecha de seguridad que afecte miles de usuarios.

Fundamentos técnicos: cómo funciona CSP

CSP opera mediante una cabecera HTTP que el servidor envía al navegador:

Content-Security-Policy: policy-directive; another-directive

Esta cabecera establece reglas sobre qué contenido puede ejecutarse. Si un script intenta cargarse desde un origen no autorizado, el navegador lo bloqueará y generará un reporte en la consola.

Directivas principales que debes conocer

Las directivas más críticas para proteger tu aplicación son:

script-src: controla desde dónde pueden cargarse scripts JavaScript. Es la defensa principal contra XSS.
default-src: política por defecto para todos los tipos de recursos no especificados explícitamente.
object-src: controla plugins como Flash (en desuso, pero aún relevante). Recomendación: siempre configurar como ‘none’.
base-uri: restringe las URLs que pueden usarse en el elemento <base>, previniendo ataques de inyección de base.
style-src: controla hojas de estilo CSS.
img-src: define orígenes permitidos para imágenes.
connect-src: limita URLs a las que el código puede conectarse (fetch, WebSocket, XMLHttpRequest).

Valores especiales: nonce, hash y unsafe-inline

CSP ofrece mecanismos para permitir scripts específicos sin abrir brechas de seguridad:

‘nonce-[valor]’: genera un token único por cada petición. Solo scripts con ese nonce específico se ejecutarán.
‘hash-[algoritmo]-[hash]’: permite scripts específicos basándose en su hash SHA-256/384/512.
‘unsafe-inline’: permite scripts inline (NO recomendado en producción, anula gran parte de la protección CSP).
‘unsafe-eval’: permite eval() y construcciones similares (evitar salvo necesidad crítica).
‘self’: permite recursos del mismo origen.
‘none’: bloquea todos los recursos de ese tipo.

Errores comunes que comprometen la seguridad

Incluso con CSP implementado, configuraciones incorrectas pueden dejar tu aplicación vulnerable. Estos son los errores más frecuentes que vemos en el ecosistema:

1. Uso excesivo de ‘unsafe-inline’

Muchos equipos implementan CSP pero mantienen ‘unsafe-inline’ en script-src porque es más fácil que refactorizar código. Esto anula gran parte de la protección contra XSS, el problema que CSP está diseñado para resolver.

2. Dominios comodín demasiado amplios

Configurar script-src https://*.ejemplo.com puede parecer conveniente, pero si cualquier subdominio está comprometido o permite subida de archivos, un atacante puede bypasear CSP.

3. Olvidar object-src

No especificar object-src ‘none’ puede permitir la carga de plugins peligrosos. Aunque Flash está en desuso, esta directiva sigue siendo relevante para una defensa en profundidad.

4. Base-uri sin restricción

Sin base-uri ‘self’, un atacante podría inyectar un elemento <base> y redirigir todos los enlaces relativos a un dominio malicioso.

Técnicas de bypass que debes conocer (perspectiva pentester)

Entender cómo los atacantes intentan evadir CSP te ayuda a configurar políticas más robustas:

Explotación de JSONP endpoints

Si tu CSP permite un dominio que ofrece endpoints JSONP, un atacante puede usarlos para ejecutar código arbitrario. Solución: audita todos los dominios en tu whitelist y elimina aquellos con JSONP expuesto.

Abuso de CDNs públicos

Permitir CDNs como cdnjs.cloudflare.com o unpkg.com es conveniente pero peligroso: contienen miles de bibliotecas, algunas con vulnerabilidades conocidas o funcionalidades que pueden explotarse.

AngularJS y bibliotecas con eval-like

Frameworks como AngularJS (versiones antiguas) incluyen funcionalidades similares a eval() que pueden usarse para bypass si el framework está en la whitelist.

Subdominios comprometidos

Como mencionamos, si permites *.tudominio.com y un subdominio permite subida de archivos o está mal configurado, un atacante puede alojar JavaScript malicioso ahí.

Mejores prácticas para implementar CSP en tu producto

Para founders construyendo productos seguros desde el inicio, estas recomendaciones son esenciales:

Empieza en modo report-only

Usa la cabecera Content-Security-Policy-Report-Only inicialmente. Esto te permite probar políticas sin romper funcionalidad existente, recibiendo reportes de violaciones.

Adopta nonces para scripts inline

Si necesitas scripts inline (ej. inicialización de configuración), usa nonces generados dinámicamente por cada request. Ejemplo:

Content-Security-Policy: script-src 'nonce-r4nd0m123'

Y en tu HTML: <script nonce='r4nd0m123'>...</script>

Sé específico con orígenes

En lugar de wildcards amplios, lista explícitamente subdominios y servicios de terceros que necesitas: script-src 'self' https://analytics.google.com https://cdn.tudominio.com

Implementa reporting

Configura report-uri o report-to para recibir notificaciones de violaciones CSP. Esto te ayuda a detectar ataques en curso y problemas de configuración.

Revisa y actualiza regularmente

Tu política CSP debe evolucionar con tu producto. Cada nueva integración (analytics, chat, pagos) requiere revisar y ajustar políticas.

Herramientas para analizar y validar tu CSP

Varias herramientas pueden ayudarte a evaluar la robustez de tu implementación:

Google CSP Evaluator: analiza tu política y señala debilidades específicas.
CSP Scanner: herramienta que identifica bypasses potenciales basándose en dominios whitelisteados.
Report URI: servicio que recolecta y analiza reportes de violaciones CSP.
Mozilla Observatory: evalúa la seguridad general de tu sitio, incluyendo CSP.

Casos de uso prácticos para startups tech

SaaS B2B con contenido de usuarios

Si tu producto permite que usuarios suban contenido o código (ej. plataformas de personalización, no-code tools), CSP es crítico. Configura políticas estrictas por defecto y usa sandboxing para contenido de terceros.

Aplicaciones fintech o healthtech

Productos que manejan datos sensibles deben implementar CSP nivel 2 o superior, con nonces, sin ‘unsafe-inline’, y con reporting activo para detectar intentos de ataque inmediatamente.

Marketplaces y plataformas de integración

Si tu producto integra múltiples servicios externos (pasarelas de pago, analytics, CRMs), necesitas una estrategia CSP modular que permita flexibilidad sin comprometer seguridad.

Conclusión

Para founders construyendo productos tech escalables, Content-Security-Policy no es solo una medida de seguridad técnica: es una declaración de compromiso con la protección de datos de tus usuarios. Implementar CSP correctamente desde etapas tempranas te ahorra vulnerabilidades costosas y genera confianza en clientes empresariales que auditan tu seguridad.

La curva de aprendizaje existe, pero las herramientas modernas y el modo report-only hacen que la adopción sea progresiva. Empieza con políticas básicas, itera basándote en reportes reales, y refina continuamente. La inversión en tiempo retorna en forma de arquitectura más resiliente y menos superficie de ataque.

Si estás evaluando soluciones de seguridad o necesitas asesoría sobre implementación, la experiencia colectiva de founders que ya pasaron por esto es invaluable.

¿Desarrollando un SaaS y quieres asegurar tu producto desde el día uno? Únete a Ecosistema Startup y conecta con founders que han implementado arquitecturas de seguridad en producción.