Evita ataques XSS con CSP: Guía esencial paso a paso

¿Por qué deberías preocuparte por los ataques XSS?

Si alguna vez pensaste que tu sitio era demasiado pequeño para ser atacado, más vale que lo pienses dos veces. Los ataques XSS (Cross-Site Scripting) no discriminan: si hay una brecha, alguien va a colarse. Y no, no es paranoia, es simplemente cómo funciona la web. Basta un campo de formulario mal validado para abrir la puerta a scripts maliciosos que pueden robar datos, manipular contenido o, peor aún, comprometer a tus usuarios sin que se den cuenta.

Según OWASP, los XSS siguen estando entre los 10 principales riesgos de seguridad web desde hace años. Así que si tienes una página, blog, tienda online o cualquier cosa que viva en Internet, blindarla con una buena política de seguridad de contenido (CSP) es más que recomendable: es urgente.

Qué es Content Security Policy (CSP) y por qué debería importarte

A ver, pongámoslo fácil: Content Security Policy (CSP) es como un filtro inteligente que le dice al navegador qué contenido puede cargar tu sitio… y cuál no. Es una capa extra de defensa que ayuda a prevenir ataques XSS, controlando desde qué lugares se permite ejecutar scripts, cargar imágenes, fuentes, estilos, entre otros.

En palabras simples: «Si no te conozco, no cargas». Así de simple, así de potente.

Cómo funciona CSP (sin volverte loco en el intento)

Cuando activas CSP en tu servidor, le estás diciendo al navegador: “Solo confía en estos recursos que te estoy nombrando”. Esto lo haces mediante directivas CSP, que son como instrucciones específicas. Algunas de las más usadas son:

• default-src: para indicar las fuentes por defecto de todos los recursos.
• script-src: para definir de dónde pueden cargarse los scripts.
• style-src: lo mismo pero con los estilos CSS.
• img-src: fuentes permitidas para imágenes.

Y así varias más.

Una política básica puede verse algo así:

Content-Security-Policy: default-src 'self'; script-src 'self' https://apis.google.com

¿El resultado? Si alguien intenta inyectar un script desde otro dominio, el navegador simplemente lo ignora. Como si no existiera. Bye bye XSS.

Beneficios reales de usar CSP (más allá del tecnicismo)

Puedes pensar que implementar esto es un quilombo, pero los beneficios lo justifican:

• Reduce drásticamente el riesgo de XSS.
• Controlás qué contenido externo se carga (ideal para evitar trackers y scripts sospechosos).
• Mejorás la confianza del usuario.
• Google lo tiene en cuenta para el ranking.

Además, si usas herramientas como Google CSP Evaluator puedes probar y ajustar tu política sin necesidad de volverte loco.

Ejemplo práctico: implementando CSP paso a paso

Supongamos que tienes una web sencilla, con Bootstrap y algún que otro script externo:

1. Identifica todos los recursos externos que usas (scripts, hojas de estilo, fuentes).
2. Armá tu política CSP inicial. Por ejemplo:

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://cdn.jsdelivr.net;
  style-src 'self' https://fonts.googleapis.com;
  font-src https://fonts.gstatic.com

3. Activa la política en el servidor. Si usás Apache, lo haces con una línea en el .htaccess. En Nginx, se puede hacer desde el bloque del sitio.
4. Testea en modo report-only. Así ves qué se bloquearía sin que se apliquen restricciones reales:

Content-Security-Policy-Report-Only: ...

5. Ajusta y refina. Siempre hay algo que olvidas.

¿Qué pasa con los nonce y hashes?

Acá se pone interesante. Si tienes scripts inline (o sea, metidos directamente en el HTML), lo más probable es que los bloquee tu CSP… a menos que uses un nonce o un hash. Un nonce es un código único que generas en cada carga de página, y que le dice al navegador: «este script está aprobado, puedes ejecutarlo».

Ejemplo:

<script nonce="RANDOM123">alert('Hola');</script>

Y en el header:

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

También podés usar hashes para validar scripts específicos. Es más seguro aún, pero también más complejo de mantener si modificás el contenido.

Mejores prácticas para implementar CSP sin dramas

• Empezá con report-only. Te va a ahorrar muchos dolores de cabeza.
• Usá herramientas como Report URI para recibir alertas cuando se bloquea contenido.
• Mantené la política actualizada cada vez que sumes contenido externo.
• No uses unsafe-inline ni unsafe-eval, salvo que estés 100% seguro (y aún así, no lo hagas).

¿Y si rompo algo sin querer?

Tranquilo. Nos pasó a todos. Por eso existe el modo report-only. Vas viendo qué se rompería sin arruinar la experiencia del usuario. Una vez que tenés todo controlado, activás la política completa y listo.

Como dijo una vez un profesor: «La seguridad no se trata de poner un candado enorme, sino de saber exactamente quién entra y por dónde».

En resumen…

La implementación de Content Security Policy para prevenir XSS no solo es necesaria: es un paso clave hacia una web más segura. No hace falta ser experto para empezar, pero sí tener ganas de aprender. Con CSP, el navegador se convierte en tu primer aliado contra los scripts maliciosos.

Así que, si querés dejar de preocuparte por inyecciones de código y empezar a dormir un poco más tranquilo, ya sabés por dónde empezar.

---

Fuentes externas útiles:

• https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
• https://owasp.org/www-project-csp/
• https://webhint.io/docs/user-guide/hints/hint-content-security-policy/
• https://csp-evaluator.withgoogle.com/
• https://report-uri.com/

Preguntas Frecuentes