La Content Security Policy (CSP) es una característica de seguridad que ayuda a proteger sitios web y aplicaciones web contra ataques como clickjacking, cross-site scripting (XSS) y otras inyecciones de código malicioso.
En términos simples, una CSP es un conjunto de reglas que restringen o permiten qué contenido puede cargarse en tu sitio web. Es un estándar de seguridad ampliamente respaldado y recomendado para cualquier persona que opera un sitio web.
En este otro artículo te explico cómo implementar las cabeceras de seguridad en Apache.
¿Por qué necesitas una Content Security Policy?
Implementar una CSP añade una capa de protección a tu sitio web al definir qué fuentes de contenido están permitidas. Estas reglas ayudan a defenderse contra:
- Ataques Cross-Site Scripting (XSS): Previene que scripts maliciosos se ejecuten en el navegador del usuario.
- Clickjacking: Evita que tu sitio sea incrustado en iframes de dominios no autorizados.
- Ejecución de Scripts Maliciosos: Restringe la carga y ejecución de JavaScript solo desde fuentes de confianza.
- Sniffing de Paquetes: Enforce HTTPS para todas las conexiones, protegiendo la transferencia de datos.
- Mejora del Rendimiento: Al reducir la carga de contenido no necesario, se mejora la velocidad del sitio.
Cómo configurar una Content Security Policy
A continuación, se presenta una guía paso a paso sobre cómo configurar una CSP para tu sitio web.
Paso 1: Definir tu CSP
Primero, debes determinar qué tipos de contenido necesita tu sitio y desde dónde se cargará. Las CSP se componen de directivas y valores de fuente que especifican qué recursos están permitidos.
Directivas comunes de CSP
- default-src: Política predeterminada para cualquier tipo de contenido no especificado.
- script-src: Fuentes permitidas para JavaScript.
- style-src: Fuentes permitidas para hojas de estilo CSS.
- img-src: Fuentes permitidas para imágenes.
- font-src: Fuentes permitidas para tipografías.
- connect-src: Fuentes permitidas para conexiones como AJAX o WebSocket.
- frame-src: Fuentes permitidas para cargar frames o iframes.
- object-src: Fuentes permitidas para objetos embebidos como
<object>o<embed>. - report-uri: URI donde se enviarán los informes de violaciones de la CSP.
Valores comunes para las directivas -src
- ‘*’: Permite cualquier URL excepto esquemas
data:,blob:,filesystem:. - ‘none’: No permite cargar recursos de ninguna fuente.
- ‘self’: Permite cargar recursos desde el mismo origen.
- ‘unsafe-inline’: Permite la ejecución de código inline (no recomendado por razones de seguridad).
- Esquemas específicos: Como
https:, para permitir solo recursos cargados vía HTTPS.
Ejemplos de CSP
- Permitir solo contenido del mismo origen:
Content-Security-Policy: default-src 'self';- Permitir imágenes de cualquier origen, pero scripts solo del mismo origen:
Content-Security-Policy: default-src 'self'; img-src *;- Bloquear completamente la carga de iframes:
Content-Security-Policy: frame-src 'none';Paso 2: Añadir la CSP a tu encabezado HTTP
La CSP se implementa generalmente a través del encabezado HTTP Content-Security-Policy. Debes configurar tu servidor web para que incluya este encabezado en las respuestas.
Configuración en diferentes servidores Web
- Apache: En el archivo
.htaccesso en la configuración del sitio, añade:
Header set Content-Security-Policy "default-src 'self'; img-src *;"- NGINX: En el bloque
server {}de tu configuración:
add_header Content-Security-Policy "default-src 'self'; img-src *;";- IIS (Internet Information Services): Utiliza el administrador de IIS para añadir un nuevo encabezado HTTP o modifica el archivo
web.config:
<system.webServer> <httpProtocol> <customHeaders> <add name="Content-Security-Policy" value="default-src 'self'; img-src *;" /> </customHeaders> </httpProtocol> </system.webServer>Paso 3: Probar tu CSP antes de implementarla
Es recomendable probar tu CSP en modo de solo reporte antes de aplicarla en producción. Puedes hacerlo utilizando el encabezado Content-Security-Policy-Report-Only. Esto te permitirá recibir informes de violaciones sin bloquear el contenido, ayudándote a ajustar la política según sea necesario.
Content-Security-Policy-Report-Only: default-src 'self'; img-src *; report-uri /csp-report-endpoint
Paso 4: Aplicar tu CSP en producción
Una vez que hayas probado y ajustado tu CSP, puedes implementarla en producción reemplazando Content-Security-Policy-Report-Only por Content-Security-Policy.
Content-Security-Policy: default-src 'self'; img-src *;
Herramientas para generar y monitorear CSP
- CSP Policy Generator: Extensiones para Chrome y Firefox que ayudan a generar políticas automáticamente.
- CSP Evaluator: Herramienta para evaluar políticas existentes y detectar posibles configuraciones inseguras.
- CSP Tester: Extensión de navegador para construir y probar políticas en tu aplicación web.
- Csper Report Collector: Herramienta para monitorear informes de violaciones de CSP.
Vulnerabilidades que CSP puede prevenir
- Ataques XSS: Al restringir las fuentes de scripts, evitas que código malicioso se ejecute en tu sitio.
- Clickjacking: Utilizando la directiva
frame-ancestorspara controlar qué dominios pueden incrustar tu sitio. - Ejecución de Código Dinámico: Bloquea el uso de
eval()y otras funciones peligrosas conscript-src 'self'. - Sniffing de Paquetes: Enforce HTTPS para todas las conexiones con directivas como
upgrade-insecure-requests.
Cómo funciona Content Security Policy
Cuando un navegador carga una página con una CSP, verifica cada recurso que intenta cargar contra las reglas definidas. Si un recurso no cumple con la política, el navegador lo bloquea y, opcionalmente, envía un informe a la URI especificada en report-uri o report-to.
Esto ayuda a prevenir que scripts o recursos no autorizados se carguen en tu sitio, protegiendo tanto al servidor como a los usuarios finales de posibles ataques.
Una vez implementadas las CSP puedes revisarlas con este scanner gratuito: https://observatory.mozilla.org/
Cómo mejora el SEO las Content Security Policy
Un sitio que emplea CSP reduce el riesgo de ataques como el cross-site scripting (XSS) y la inyección de código malicioso, lo que minimiza las probabilidades de ser bloqueado o marcado como inseguro por navegadores y motores de búsqueda.
Además, Google prioriza la seguridad del sitio web, y una página con buenas prácticas de seguridad, como el uso de CSP, tiene menos posibilidades de ser penalizada o de experimentar caídas en su posicionamiento debido a infecciones de malware o ataques de seguridad.
