Pega o crea una CSP, revisa la política y exporta fragmentos de cabecera para HTTP, Nginx o Apache. El análisis ocurre en tu navegador; nada se sube.
Se ejecuta localmente en tu navegadorPega una CSP existente para revisarla o utiliza el generador de la derecha. La herramienta solo analiza el texto introducido.
Introduce las expresiones de origen sin el nombre de la directiva. Deja un campo vacío para omitirla.
Utiliza HSTS solo cuando HTTPS esté correctamente configurado en todos los subdominios relevantes. Contrasta los valores generados con los requisitos de tu aplicación.
Build a CSP, then generate header snippets.
Build a CSP, then generate header snippets.
Build a CSP, then generate header snippets.
La CSP debe ajustarse a los recursos que la aplicación necesita realmente. Despliégala con cautela, prueba primero el modo report-only y no copies políticas entre sitios sin revisar scripts, frames, APIs y recursos de terceros.
Esta página convierte una Content-Security-Policy en tres cosas útiles: una revisión directiva por directiva del texto que escribes, una política completa montada con el generador y fragmentos de cabecera listos para pegar en Nginx o Apache. Lee la política como texto; nunca solicita tu sitio.
Todo se ejecuta en la pestaña y ninguna entrada se envía a VoriTools, así que puedes revisar una política que aún no está publicada.
El texto se divide por puntos y coma, y cada directiva se lee como un nombre seguido de su lista de orígenes. Los nombres de directiva no distinguen mayúsculas; el resto se compara tal como está escrito. Primero se comprueban dos cuestiones estructurales, porque el navegador las resuelve por su cuenta y casi nunca como espera quien escribe la política: si una directiva aparece dos veces, se usa el primer valor y se ignoran los siguientes; si 'none' aparece junto a otros orígenes, 'none' se ignora en lugar de aplicarse.
La revisión es heurística, no un validador. Señala lo que más debilita una política en la práctica (falta de default-src, 'unsafe-inline' o 'unsafe-eval' en script-src, un origen comodín o data: para scripts, y la ausencia de object-src, base-uri, frame-ancestors o form-action), pero una política completa puede no servir a tu aplicación, y otra que aquí recibe un aviso puede ser correcta.
Las tres salidas llevan las mismas cabeceras: el valor de Content-Security-Policy que hayas escrito, más las cuatro cabeceras opcionales que marques. La vista HTTP son líneas Nombre: valor; la de Nginx envuelve cada cabecera en add_header ... always; para que también se envíe en las respuestas de error; la de Apache usa Header always set ... . Las comillas y barras invertidas de la política se escapan según la sintaxis de destino.
Las cabeceras opcionales son valores fijos: X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy: camera=(), geolocation=(), microphone=() y Strict-Transport-Security: max-age=63072000; includeSubDomains. Revisa cada valor frente a tus requisitos; en particular, HSTS fija HTTPS en el navegador durante el max-age que envíes, así que añádelo solo cuando todos los subdominios implicados estén listos.
Una CSP se aplica en respuestas reales, no en este editor. Una directiva que aquí parece estricta puede romper un script de pago, una fuente o un estilo en línea que la aplicación necesita, y la consola del navegador indica exactamente qué origen se bloqueó. Despliega una política nueva primero con Content-Security-Policy-Report-Only en un entorno de pruebas, y después actívala y sigue revisando los informes.
Los fragmentos son puntos de partida para tu configuración de servidor, no un sustituto. Que una cabecera llegue al cliente depende de tu servidor web, de cualquier CDN o proxy intermedio y de la ruta que sirve la página; comprueba las cabeceras reales tras el despliegue con el panel de red del navegador o un cliente de línea de comandos.