EN
navegar Enter abrir Esc cerrar
Herramienta de Seguridad

Generador de Content Security Policy (CSP)

Crea políticas de seguridad CSP visuales para Nginx, Apache, PHP y etiquetas Meta previniendo ataques XSS e inyección de datos.

Revisión Técnica de Estándar · Última revisión: 29 de agosto de 2026Fuentes oficiales: W3C· MDN Web Docs
default-src
script-src (Scripts Javascript)
style-src (Estilos CSS)
img-src (Imágenes)
font-src (Tipografías)

Guía Completa de Seguridad Web: Content Security Policy (CSP), Cabeceras HTTP y Prevención XSS

La cabecera de seguridad Content Security Policy (CSP) es el mecanismo defensivo más potente implementado por los navegadores modernos para neutralizar ataques de Cross-Site Scripting (XSS), inyección de scripts no autorizados, robo de cookies de sesión y clickjacking.

Al definir una lista explícita de orígenes de confianza para la carga de JavaScript, hojas de estilo CSS, imágenes, fuentes y conexiones API, CSP garantiza que ningún recurso ajeno o inyectado pueda ejecutarse en los dispositivos de tus usuarios.

Estructura de Directivas Principales en CSP

Configura directivas especializadas para cada tipo de contenido:

  • default-src: Actúa como política base por defecto para cualquier tipo de recurso no especificado.
  • script-src: Controla los orígenes autorizados para ejecutar JavaScript, bloqueando código inyectado.
  • style-src y font-src: Permite cargar fuentes y estilos desde CDNs legítimas (como Google Fonts o Cloudflare).
  • img-src: Restringe la descarga de imágenes y el uso de esquemas en base64 (data:).

Despliegue en Servidor (Nginx / Apache) vs Etiqueta HTML <meta>

La mejor práctica consiste en inyectar la cabecera directamente desde el servidor web Nginx o Apache mediante la directiva add_header Content-Security-Policy. En alojamientos estáticos o entornos donde no se tiene acceso a la configuración del servidor, la etiqueta <meta http-equiv="Content-Security-Policy"> proporciona una protección esencial.

Buenas Prácticas: Eliminación de 'unsafe-inline'

Aunque durante el desarrollo inicial se recurre habitualmente a 'unsafe-inline', en entornos de producción se recomienda aislar los scripts en archivos externos o proteger bloques inline mediante identificadores criptográficos únicos (nonces) o hashes SHA-256.

Ejemplo Práctico

Ejemplo 1: Política Estándar para Aplicación Web Moderna
Entrada: Por Defecto: 'self' | Scripts: 'self' cdnjs.cloudflare.com | Estilos: 'self' fonts.googleapis.com | Fuentes: fonts.gstatic.com
Resultado generado: default-src 'self'; script-src 'self' https://cdnjs.cloudflare.com; style-src 'self' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com;

Garantiza que solo se carguen recursos del propio dominio y de las CDNs de confianza especificadas.

Ejemplo 2: Integración de Cabecera en Servidor Nginx
Entrada: Configuración dentro del bloque server {} de Nginx
Resultado generado: add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self';" always;

Añade la directiva de seguridad en todas las respuestas HTTP emitidas por el servidor web.

Cómo Generar e Implementar Cabeceras CSP en 4 Pasos

1

Configura las Fuentes por Defecto y Scripts

Establece default-src e indica los dominios de confianza que sirven tus archivos JavaScript.

2

Añade Orígenes de Estilos, Fuentes e Imágenes

Incluye las CDNs de confianza para hojas de estilo (style-src), tipografías (font-src) e imágenes (img-src).

3

Pulsa "Generar Cabeceras CSP"

El sistema compilará al instante las cadenas de configuración para Nginx y etiquetas HTML <meta>.

4

Implementa en tu Servidor o HTML

Copia la directiva add_header en la configuración de Nginx/Apache o la etiqueta <meta> en el <head> de tu web.

Preguntas Frecuentes sobre Cabeceras y Seguridad CSP

¿Qué es una política de seguridad de contenido (Content Security Policy o CSP)?

Content Security Policy (CSP) es un estándar de seguridad web de la W3C implementado mediante cabeceras HTTP que indica al navegador qué orígenes y dominios de confianza están autorizados para cargar scripts, estilos, tipografías, imágenes y conexiones de red en tu sitio web.

¿Cómo protege la cabecera CSP frente a ataques de Cross-Site Scripting (XSS)?

Al restringir los orígenes permitidos (por ejemplo, script-src 'self' https://cdn.ejemplo.com), el navegador bloquea automáticamente cualquier script malicioso o inyección de código que un atacante intente ejecutar en la página, impidiendo el robo de sesiones y la exfiltración de datos.

¿Qué diferencia existe entre configurar CSP en el servidor (Nginx/Apache) o con una etiqueta &lt;meta&gt;?

La configuración a nivel de servidor mediante cabeceras HTTP (Nginx o Apache) es la más segura y completa, ya que permite directivas avanzadas como frame-ancestors (protección contra clickjacking) y report-to. La etiqueta HTML <meta> es útil en alojamientos estáticos pero tiene directivas limitadas.

¿Por qué se desaconseja el uso de 'unsafe-inline' y 'unsafe-eval' en entornos de producción?

'unsafe-inline' permite la ejecución de scripts en línea sin validar y eventos inline (onclick), reduciendo la eficacia contra XSS. 'unsafe-eval' autoriza el uso de eval() para transformar texto en código. Para la máxima seguridad, se recomienda migrar a nonces ('nonce-...') o hashes SHA-256.

¿Cuáles son las directivas CSP indispensables en cualquier proyecto web?

Las directivas esenciales son default-src (política por defecto), script-src (archivos JavaScript), style-src (hojas de estilo CSS), img-src (gráficos e imágenes), font-src (fuentes web), connect-src (peticiones Fetch/AJAX/WebSockets) y frame-ancestors (prevención de enmarcado).

Compartir esta herramienta

Ayuda a otras personas compartiendo esta herramienta gratuita.