Política CSP: Cómo evitar ataques XSS

📅 Publicado el 10 de agosto, 2026 · Por Equipo RedServicio

¿Qué es y por qué necesitas una Política CSP evitar XSS?

La seguridad web no es algo opcional hoy en día. Si tienes un blog, una tienda o cualquier proyecto online, sabes que los atacantes siempre están buscando la rendija. Una de las viejas conocidas en este juego es el Cross-Site Scripting (XSS). Es la vulnerabilidad estrella para inyectar scripts maliciosos y fastidiar la visita de usuarios desprevenidos. Aquí es donde se vuelve vital la Política CSP evitar XSS (Content Security Policy). Funciona como una capa extra. Le dice al navegador qué fuentes son dignas de confianza y cuáles no.

En cristiano: la CSP actúa como una lista blanca. Tú le das las instrucciones al navegador: «Carga scripts de este dominio, imágenes de este otro y estilos de este tercero. Nada más». Si alguien intenta colar un script desde un dominio que no autorizaste, el navegador lo corta de raíz. Implementar una Política CSP evitar XSS ya no es un lujo, es un estándar que cualquier administrador de sistemas o desarrollador que se respete debe tener en su radar.

Entendiendo las directivas básicas de la CSP

Para que esto funcione, tienes que entender el mecanismo. Las cabeceras CSP se arman con directivas. Cada una controla un tipo de recurso. La estructura es simple: Directiva Valor. Pero ojo, los detalles importan. Estas son las claves para blindar tu aplicación:

• default-src: Es tu red de seguridad. Si olvidas definir una directiva específica (como script-src o img-src), el navegador recurre a esta. Por seguridad, es mejor empezar con ‘none’ y abrir la mano solo con lo indispensable.
• script-src: El corazón de la operación. Define de dónde vienen los JavaScript. Si quieres prevenir XSS, esto es lo primero que ajustas. Usa ‘self’ para permitir solo lo que viene de tu propio dominio.
• style-src: Controla el CSS. No lo dejes al azar. Lo creas o no, el CSS también puede usarse para atacar.
• img-src: Fija las fuentes válidas para imágenes. Si usas un CDN o herramientas de analítica que cargan imágenes, agrégalos aquí.
• connect-src: Limita a dónde puede conectar tu sitio (AJAX, Fetch, WebSockets).

Modos de implementación: Report-Only vs. Enforcement

No lances la cabecera a lo loco. Antes de bloquear cosas, debes saber que hay dos formas de hacer esto. Saltarte el paso de prueba puede dejar tu sitio medio roto si bloqueas un script bueno por error.

1. Content-Security-Policy-Report-Only

Este es el modo ensayo. Al poner esta cabecera, el navegador no bloquea nada. Solo envía un reporte a una URL que tú definas (con report-uri o report-to) avisando de qué habría bloqueado. Es la mejor forma de auditar tu sitio durante unas semanas antes de activar la protección real.

2. Content-Security-Policy

Una vez revisados los reportes y corregidos los errores (sacando scripts en línea, agregando dominios de confianza), cambias a este modo. Aquí el navegador se pone serio y bloquea cualquier carga no autorizada. En entornos gestionados como los de RedServicio, es vital probar esto en un entorno de staging (pruebas) antes de tocar producción.

Ejemplos de configuración para Policy CSP evitar XSS

Vamos a ver código. La forma más habitual de pegarle a esto es desde la configuración de tu servidor web.

Implementación en Apache (.htaccess)

Si estás en Apache, añade esto a tu archivo .htaccess en la raíz. Este ejemplo permite scripts solo de tu dominio y de Google Analytics:

<IfModule mod_headers.c>
    Header set Content-Security-Policy "default-src 'self'; script-src 'self' https://www.google-analytics.com; object-src 'none'; base-uri 'self';"
</IfModule>

Mira bien esto: object-src ‘none’ es excelente para bloquear plugins viejos como Flash o Java, que son un blanco fácil para ataques. base-uri ‘self’ evita que inyecten etiquetas <base> maliciosas.

Implementación en Nginx (nginx.conf)

Para los de Nginx, la directiva va en el bloque server o location:

add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://cdn.ejemplo.com; style-src 'self' 'unsafe-inline';" always;

Ojo al parámetro «always». Asegura que la cabecera se envíe incluso si hay errores de respuesta. En este caso se usó ‘unsafe-inline’ en estilos porque a veces los CMS lo exigen, aunque lo ideal es quitarlo si puedes.

Implementación en PHP (header())

Si no tienes acceso al servidor, envía la cabecera desde PHP. Eso sí, asegúrate de que se ejecute antes de cualquier salida HTML:

<?php
header("Content-Security-Policy: default-src 'self'; script-src 'self';");
?>

Uso de Nonces y Hashes para scripts inline

A veces, la web moderna te obliga a usar pequeños trozos de código en línea. Sobre todo si usas herramientas de optimización que inyectan CSS crítico o scripts de configuración. Para no caer en ‘unsafe-inline’, existen los nonces (números de un solo uso).

Un nonce es un valor aleatorio que genera tu servidor para cada petición. Lo pones en la cabecera CSP y también en el atributo nonce de la etiqueta script. Si el valor no cuadra, el navegador no ejecuta nada.

Ejemplo en cabecera:

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

Ejemplo en HTML:

<script nonce="EDNnf03nceIOfn39fn3e9h3sdfa">
  // Código JS seguro
</script>

Así mantienes la Política CSP evitar XSS a raya. Permites solo ese script específico y bloqueas cualquier inyección que no tenga el nonce exacto.

Cómo depurar violaciones de la CSP

Activada la política (incluso en Report-Only), necesitas saber qué falla. Las violaciones llegan como documentos JSON a tu endpoint.

Para capturarlos, configura la directiva report-uri. Está en desuso en favor de report-to, pero la primera tiene un soporte amplio y es más rápida de implementar:

Content-Security-Policy: default-src 'self'; report-uri /csp-violation-report-endpoint;

En el servidor, un script simple en PHP te sirve para guardar estos datos en un log:

<?php
// csp-violation-report-endpoint.php
$input = file_get_contents('php://input');
file_put_contents('csp-logs.txt', $input . PHP_EOL, FILE_APPEND);
?>

Revisar esos logs te dirá qué está siendo bloqueado (un banner, un widget social, una fuente de Google) y te permitirá ajustar las reglas con precisión.

Conclusión

Implementar una Política CSP evitar XSS es de las mejores decisiones que puedes tomar para endurecer tu sitio contra inyecciones de código. Requiere un poco de paciencia al principio para ajustar todo, pero la ganancia en seguridad es enorme. Al limitar los orígenes, le cierras la puerta a los ciberdelincuentes.

La seguridad no es un producto, es un proceso. Empieza con el modo «Report-Only», mira los logs, ajusta las directivas y activa el cumplimiento poco a poco. Si buscas un hosting estable y seguro donde desplegar todo esto con tranquilidad, en RedServicio tenemos infraestructuras listas y soporte técnico 24/7 para ayudarte a configurar estas protecciones. Cuida tu reputación y la confianza de tus usuarios.