Un nonce CSP es un valor único y aleatorio generado por carga de página que ayuda a validar los scripts en línea legítimos dentro de una Política de Seguridad de Contenidos. Al añadir este nonce tanto al encabezado CSP como a las etiquetas de script permitidas, los desarrolladores pueden permitir scripts en línea específicos manteniendo al mismo tiempo fuertes protecciones XSS. Este enfoque es particularmente útil cuando la inserción dinámica de scripts es necesaria pero se desea una CSP estricta.
Un nonce de CSP (número usado una sola vez) es un token aleatorio e impredecible que el servidor genera en cada respuesta y coloca en dos lugares: la fuente nonce-... de la cabecera Content-Security-Policy y un atributo nonce equivalente en cada <script> o <style> inline que quiere permitir. El navegador ejecuta un script inline solo cuando su atributo nonce coincide con el valor declarado en la cabecera para esa carga concreta de la página. Como el token se regenera en cada petición y nunca es predecible, el marcado que un atacante inyecte más tarde no puede llevar un nonce válido, así que el navegador se niega a ejecutarlo. Esto le permite a un sitio conservar los scripts inline que realmente necesita mientras elimina el permiso general unsafe-inline del que depende el XSS.
La mayoría de las defensas contra XSS se derrumban en cuanto una política tiene que permitir unsafe-inline, porque esa palabra clave le dice al navegador que confíe en todo script inline, incluido cualquiera que un atacante logre inyectar. Una política basada en nonce elimina esa palabra clave: solo puede ejecutarse el código inline que el servidor marcó deliberadamente con el token actual. Esto reduce la superficie de ataque para el XSS reflejado, almacenado y basado en el DOM sin tener que mantener largas listas de permitidos de hosts externos, y neutraliza los manejadores de eventos inyectados y las etiquetas de script inline colocadas a través de una plantilla vulnerable. El nonce es la vía práctica hacia una CSP estricta, la configuración que recomiendan los equipos de seguridad, en páginas reales que todavía dependen de algo de JavaScript inline.
Genera el nonce a partir de una fuente aleatoria criptográficamente segura (al menos 128 bits) y emite uno nuevo por cada respuesta; reutilizar un nonce en páginas cacheadas anula su propósito. Nunca lo coloques donde un atacante pueda leerlo y devolvértelo. Combínalo con strict-dynamic para que los scripts de confianza puedan cargar sus propias dependencias, y mantén una lista de permitidos de hosts como recurso alternativo para navegadores antiguos. Como un nonce sigue confiando en lo que haga un script permitido en tiempo de ejecución, no puede detener un archivo de terceros comprometido. cside complementa aquí a la CSP enrutando los scripts de terceros a través de un proxy híbrido y analizando la carga real, bloqueando en tiempo real el comportamiento malicioso que un nonce válido habría dejado pasar sin más.
Sí. Un nonce debe generarse de nuevo en cada respuesta HTTP usando un generador aleatorio seguro. Si cacheas una página junto con su nonce, o reutilizas el mismo valor, un atacante que observe un nonce válido podría reproducirlo dentro del marcado inyectado, lo que anula la protección. Las páginas estáticas o cacheadas normalmente necesitan hashes en su lugar.
Ambos permiten que scripts inline concretos se ejecuten bajo una política estricta. Un nonce es un token aleatorio por petición que se añade a la etiqueta y a la cabecera, ideal para páginas renderizadas en el servidor. Un hash es un resumen fijo del contenido exacto del script, más adecuado para contenido estático o cacheado donde no puedes estampar un token nuevo en cada respuesta.
We answer client-side security questions every day. Bring yours.