Toolypet
Herramientas de Seguridad/Constructor CSP

Constructor CSP

Construye cabeceras Content-Security-Policy visualmente

Preajustes

Directivas

Default fallback for other directives

Controls allowed JavaScript sources

Controls allowed CSS sources

Controls allowed image sources

Controls allowed font sources

Controls allowed fetch/XHR/WebSocket targets

Controls allowed iframe sources

Controls allowed plugin sources (Flash, etc.)

Restricts URLs for <base> element

Restricts form submission targets

Controls who can embed this page

Upgrade HTTP to HTTPS automatically

Opciones

Cuando está habilitado, las violaciones se reportan pero no se bloquean. Útil para pruebas.

Cabecera CSP Generada

Content-Security-Policy: default-src 'self'

Ejemplos de Implementación

add_header Content-Security-Policy "default-src 'self'";
Header set Content-Security-Policy "default-src 'self'"
<meta http-equiv="Content-Security-Policy" content="default-src 'self'">

Guía del Constructor CSP

Aprende a crear cabeceras Content-Security-Policy para proteger tu sitio web

¿Qué es Content-Security-Policy?

Content-Security-Policy (CSP) es una cabecera de respuesta HTTP que ayuda a prevenir ataques de cross-site scripting (XSS), clickjacking y otras inyecciones de código. Te permite especificar qué fuentes de contenido pueden cargarse en tu sitio web, dándote control granular sobre scripts, estilos, imágenes y otros recursos.

Cómo Usar

  1. Elige un preajuste (Estricto, Moderado o Relajado) como punto de partida
  2. Habilita y configura directivas individuales según tus necesidades
  3. Revisa las advertencias de seguridad y ajusta la configuración en consecuencia
  4. Copia la cabecera generada y agrégala a la configuración de tu servidor web

Mejores Prácticas

Preguntas Frecuentes

¿Qué pasa si configuro CSP demasiado estricto?

Si tu CSP es demasiado estricto, los recursos legítimos pueden ser bloqueados, rompiendo la funcionalidad de tu sitio web. Por eso se recomienda comenzar con el modo Solo Reporte. En este modo, las violaciones se reportan a tu servidor (si configuras un report-uri) pero no se bloquean realmente, permitiéndote identificar problemas antes de aplicar la política.

¿Cuál es la diferencia entre 'self' y 'none'?

'self' permite contenido solo del mismo origen (mismo protocolo, host y puerto) que tu sitio web. 'none' bloquea todo el contenido de ese tipo. Por ejemplo, object-src 'none' previene que todos los plugins (Flash, Java, etc.) se carguen, lo cual es una práctica de seguridad recomendada.

¿Por qué 'unsafe-inline' se considera peligroso?

'unsafe-inline' permite scripts y estilos en línea, lo que anula gran parte de la protección XSS de CSP. Los atacantes que pueden inyectar HTML también pueden inyectar scripts en línea. En su lugar, usa nonces (script-src 'nonce-random123') o hashes (script-src 'sha256-...') para permitir scripts en línea específicos mientras bloqueas los inyectados.

¿Cómo permito Google Analytics u otros scripts de terceros?

Agrega el dominio específico a tu directiva script-src. Para Google Analytics, podrías necesitar: script-src 'self' https://www.googletagmanager.com https://www.google-analytics.com. También agrega sus dominios a connect-src para llamadas API y a img-src para píxeles de seguimiento.

¿Puede CSP reemplazar otras cabeceras de seguridad?

No, CSP complementa otras cabeceras de seguridad. También deberías usar: X-Content-Type-Options: nosniff, X-Frame-Options (aunque frame-ancestors en CSP puede reemplazarlo), X-XSS-Protection, Strict-Transport-Security (HSTS) y Referrer-Policy. Cada cabecera aborda diferentes preocupaciones de seguridad.