Política de seguridad de contenido en React y Next.js: una guía práctica de CSP con nonces y strict-dynamic [2026]

Introducción

La política de seguridad de contenido (CSP) es la defensa más eficaz contra el Cross-Site Scripting (XSS) en las aplicaciones web modernas — y, sin embargo, sigue siendo uno de los controles de seguridad más malentendidos y peor implementados del ecosistema React.

Una encuesta de 2025 a 300 startups SaaS descubrió que solo el 12% tenía una CSP desplegada y, de ellas, más del 70% usaba una política basada en listas de permitidos (allowlist) que proporcionaba una protección real mínima. El problema no es que los desarrolladores no se preocupen por la seguridad: es que la CSP tiene fama de ser dolorosa de implementar, fácil de romper y difícil de depurar.

Esta guía lo cambia. Aprenderás a implementar una política de seguridad de contenido de nivel producción para aplicaciones React y Next.js usando el patrón nonce + strict-dynamic, el enfoque recomendado por el W3C y el equipo de seguridad de Google para aplicaciones de una sola página (SPA) modernas. Cubriremos la generación de nonces, la configuración de middleware, los reportes y una lista de verificación de auditoría completa que puedes usar hoy mismo.

Cómo funciona realmente la CSP

En esencia, la CSP es una lista de permitidos declarativa que indica al navegador qué recursos puede cargar y ejecutar en tu página. Se entrega mediante una cabecera de respuesta HTTP:

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

Esta cabecera le dice al navegador: "Solo ejecuta scripts del mismo origen y de apis.google.com. Todo lo demás queda bloqueado."

La magia de la CSP es que, aunque un atacante consiga inyectar una etiqueta <script> en tu página, el navegador se niega a ejecutarla a menos que el origen de ese script coincida con la política. Para aplicaciones React, donde la mayoría de los vectores XSS implican inyectar elementos script o manejadores de eventos en línea, esto es un cambio de juego.

La estrategia CSP moderna: nonces

El enfoque antiguo de la CSP era una lista de permitidos de dominios:

script-src 'self' https://cdn.example.com https://analytics.example.com

Esto tiene dos problemas fatales:

1. Compromiso de CDN: si cualquier CDN de la lista de permitidos se ve comprometida, toda tu CSP queda derrotada. Un atacante puede alojar scripts maliciosos en el dominio permitido.
2. Ataques JSONP y de gadgets: muchos CDN alojan librerías JavaScript con endpoints JSONP que pueden abusarse para ejecutar código arbitrario.

El enfoque moderno es la CSP basada en nonces:

script-src 'nonce-aB3dE9xZ1k' 'strict-dynamic'

Un nonce es un token criptográficamente aleatorio y de un solo uso que el servidor genera para cada respuesta HTTP. El servidor incrusta este nonce en cada etiqueta <script> de confianza:

<script nonce="aB3dE9xZ1k">
  // Script en línea de confianza
</script>
<script src="/app.js" nonce="aB3dE9xZ1k"></script>

El navegador solo ejecuta los scripts que llevan el nonce correcto. Todo lo demás — incluidos los scripts inyectados por atacantes — queda bloqueado, independientemente de su procedencia.

CSP basada en nonces en Next.js

Implementar una CSP basada en nonces en Next.js requiere generar un nonce nuevo en cada petición y adjuntarlo tanto a la cabecera CSP como a tu HTML renderizado.

Paso 1: generación del nonce en el middleware

El enfoque más limpio es generar el nonce en el middleware de Next.js y adjuntarlo a la petición:

// middleware.ts
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

// Generación de nonce criptográficamente segura usando la Web Crypto API
function generateNonce(): string {
  const buffer = new Uint8Array(32);
  crypto.getRandomValues(buffer);
  return Array.from(buffer)
    .map(b => b.toString(16).padStart(2, '0'))
    .join('');
}

export function middleware(request: NextRequest) {
  const nonce = generateNonce();
  const requestHeaders = new Headers(request.headers);

  // Pasa el nonce a los server components mediante la cabecera de petición
  requestHeaders.set('x-nonce', nonce);

  const response = NextResponse.next({
    request: {
      headers: requestHeaders,
    },
  });

  // Construye la cabecera CSP
  // Usar 'strict-dynamic' significa que no necesitamos hosts CDN en la lista de permitidos
  const csp = [
    `default-src 'self'`,
    `script-src 'nonce-${nonce}' 'strict-dynamic'`,
    `base-uri 'self'`,
    `form-action 'self'`,
    // Report-URI para el reporte de violaciones (más sobre esto adelante)
    `report-uri /api/csp-report`,
  ].join('; ');

  response.headers.set('Content-Security-Policy', csp);

  return response;
}

export const config = {
  matcher: [
    // Aplica a todas las rutas excepto rutas de API y archivos estáticos
    '/((?!api|_next/static|_next/image|favicon.ico).*)',
  ],
};

Paso 2: pasar el nonce a los Server Components y scripts

Los Server Components de Next.js necesitan acceso al nonce para añadirlo a las etiquetas <script> renderizadas y a los manejadores de eventos en línea:

// lib/nonce.ts
import { headers } from 'next/headers';

export async function getNonce(): Promise<string> {
  const headersList = await headers();
  return headersList.get('x-nonce') || '';
}

Ahora, úsalo en tu layout para añadir el nonce a los scripts de Next.js:

// app/layout.tsx
import type { Metadata } from 'next';
import { headers } from 'next/headers';

export const metadata: Metadata = {
  title: 'My App',
  description: 'Secured with CSP',
};

export default async function RootLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  const headersList = await headers();
  const nonce = headersList.get('x-nonce') || '';

  return (
    <html lang="en">
      <head>
        {/* Mantén el nonce en una meta etiqueta para que los client components puedan referenciarlo */}
        <meta name="csp-nonce" content={nonce} />
      </head>
      <body>
        {children}
        {/* Next.js necesita críticamente el nonce en sus scripts inyectados */}
        <script
          nonce={nonce}
          dangerouslySetInnerHTML={{
            __html: `/* Los scripts de arranque de Next.js se consideran de confianza vía nonce */`,
          }}
        />
      </body>
    </html>
  );
}

El problema del nonce en los scripts de Next.js

Este es el detalle crítico que la mayoría de las guías omiten: Next.js inyecta sus propios scripts en tiempo de ejecución — los chunks del runtime de Next.js, el propio React y los módulos empaquetados con webpack. Estos scripts no pasan automáticamente por el nonce generado en tu middleware.

Para que funcione, necesitas configurar Next.js para que use el nonce:

// next.config.ts
import type { NextConfig } from 'next';

const nextConfig: NextConfig = {
  // ... tu otra configuración
  experimental: {
    // En Next.js 16, puedes pasar una función proveedora de nonce
    // al cargador de scripts del App Router
  },
};

export default nextConfig;

En Next.js 15+, el enfoque recomendado es modificar la carga de next/dynamic o usar el patrón useReportWebVitals con un componente Script personalizado que acepte el nonce. El patrón de producción más simple es:

// components/ScriptWithNonce.tsx
'use client';

import Script from 'next/script';
import { useMemo } from 'react';

export function ScriptWithNonce(
  props: React.ComponentProps<typeof Script>
) {
  const nonce = useMemo(() => {
    const meta = document.querySelector('meta[name="csp-nonce"]');
    return meta?.getAttribute('content') || '';
  }, []);

  return <Script {...props} nonce={nonce} />;
}

Para una solución más robusta, parchea next/script globalmente envolviéndolo en un proveedor que lea la meta etiqueta del nonce:

// components/NonceProvider.tsx
'use client';

import React, { createContext, useContext } from 'react';

const NonceContext = createContext<string>('');

export function NonceProvider({ children }: { children: React.ReactNode }) {
  // Lee el nonce de la meta etiqueta establecida en el layout
  const nonce =
    typeof document !== 'undefined'
      ? document
          .querySelector('meta[name="csp-nonce"]')
          ?.getAttribute('content') || ''
      : '';

  return (
    <NonceContext.Provider value={nonce}>
      {children}
    </NonceContext.Provider>
  );
}

export function useNonce(): string {
  return useContext(NonceContext);
}

strict-dynamic: por qué importa

'strict-dynamic' es la directiva CSP que hace práctica la política basada en nonces para aplicaciones JavaScript modernas. Esto es lo que hace:

Cuando un script con un nonce válido carga otro script (p. ej., añadiendo dinámicamente una etiqueta <script> al DOM), strict-dynamic le dice al navegador: "Confía también en el script cargado dinámicamente, porque lo ha cargado una fuente de confianza."

Sin strict-dynamic, tu CSP necesitaría enumerar explícitamente cada posible origen de script:

script-src 'nonce-aB3dE9xZ1k' 'self' https://cdn.jsdelivr.net https://www.googletagmanager.com

Con strict-dynamic, la política se convierte en:

script-src 'nonce-aB3dE9xZ1k' 'strict-dynamic'

Tus bundles JavaScript de confianza pueden importar o añadir dinámicamente cualquier script que necesiten — componentes React cargados de forma diferida, fragmentos de analítica, widgets de terceros — y el navegador los acepta porque provienen de una fuente de confianza (con nonce).

Compatibilidad con navegadores

| Navegador | Soporte de strict-dynamic | |---------|-------------------------| | Chrome 52+ | [V] Completo | | Firefox 52+ | [V] Completo | | Safari 15.4+ | [V] Completo | | Edge 79+ | [V] Completo |

Para navegadores antiguos que no soportan strict-dynamic, incluye un respaldo:

script-src 'nonce-aB3dE9xZ1k' 'strict-dynamic' 'unsafe-inline' https:

Los navegadores antiguos ignoran strict-dynamic y recurren a unsafe-inline (menos seguro, pero evita roturas). Los navegadores modernos procesan strict-dynamic e ignoran el respaldo.

Gestión de eval y estilos en línea

El problema de unsafe-eval

React DevTools, Redux DevTools, el hot module replacement de webpack y algunos SDK de terceros usan eval() o new Function() internamente. La CSP los bloquea por defecto.

Tienes tres opciones:

1. Omitir la CSP en builds de desarrollo — actívala solo en producción:

// middleware.ts
export function middleware(request: NextRequest) {
  if (process.env.NODE_ENV === 'development') {
    return NextResponse.next();
  }
  // ... lógica CSP
}

2. Usar unsafe-eval con conocimiento de causa — aceptable si auditas tu uso de eval:

script-src 'nonce-aB3dE9xZ1k' 'strict-dynamic' 'unsafe-eval'

3. Eliminar las dependencias de eval — la opción más segura. Muchas librerías tienen alternativas sin eval:
   • Usa lodash en lugar de underscore (que usa el constructor Function)
   • Evita Redux DevTools en producción
   • Usa un build de producción que elimine el código HMR de webpack

El reto de style-src

React inyecta estilos en línea para CSS dinámico (p. ej., style={{ color: 'red' }}). Para permitirlo con CSP necesitas una de estas opciones:

1. unsafe-inline en style-src (lo más común, aceptable para aplicaciones internas):

style-src 'self' 'unsafe-inline'

2. Estilos basados en nonces:

style-src 'nonce-aB3dE9xZ1k'

Después pasa el nonce a todas las etiquetas <style> en línea.

3. CSS-in-JS compatible con CSP — librerías como styled-components soportan el atributo nonce:

import { StyleSheetManager } from 'styled-components';

function App({ nonce }: { nonce: string }) {
  return (
    <StyleSheetManager nonce={nonce}>
      <YourApp />
    </StyleSheetManager>
  );
}

Para los usuarios de Tailwind CSS (v4 con motor JIT), los estilos se emiten como un único archivo CSS en los builds de producción, no en línea. Esto significa que no necesitas unsafe-inline para estilos en producción: el CSS generado por Tailwind se carga mediante etiquetas <link>, que la CSP gestiona con style-src 'self':

style-src 'self';

CSP para integraciones de terceros

Los scripts de terceros son la razón número uno por la que los desarrolladores rompen su CSP. Así se manejan las integraciones comunes.

Google Analytics / gtag

Google Analytics recomienda dos etiquetas script. Con CSP basada en nonces:

<!-- script gtag con nonce -->
<script nonce="aB3dE9xZ1k" async
  src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXX">
</script>
<script nonce="aB3dE9xZ1k">
  window.dataLayer = window.dataLayer || [];
  function gtag(){ dataLayer.push(arguments); }
  gtag('js', new Date());
  gtag('config', 'G-XXXXXXX');
</script>

Como strict-dynamic está establecido, los scripts cargados dinámicamente por gtag se consideran de confianza automáticamente.

Stripe.js / PayPal / SDK de pagos

Los SDK de pago suelen cargar scripts adicionales en tiempo de ejecución. Con strict-dynamic, tu script de integración de pagos con nonce puede cargar Stripe.js dinámicamente y el navegador confía en él:

'use client';

import { useEffect } from 'react';

export function StripeCheckout() {
  useEffect(() => {
    // Stripe carga scripts adicionales dinámicamente
    // Con strict-dynamic, se consideran de confianza automáticamente
    const stripe = await loadStripe('pk_test_xxxx');
    // ...
  }, []);

  return <div id="checkout">...</div>;
}

Sentry / seguimiento de errores

El SDK de Sentry carga sus scripts de transporte dinámicamente. Con strict-dynamic, solo necesitas que el bundle inicial de Sentry tenga un nonce:

<Script
  src="/sentry.js"
  nonce={nonce}
  strategy="beforeInteractive"
/>

Reportes de CSP

Las violaciones de CSP ocurren — los scripts de terceros cambian, los desarrolladores cometen errores y los comportamientos de los navegadores difieren. Nunca despliegues una CSP sin un mecanismo de reportes.

Modo de solo reporte (Report-Only)

Antes de imponer una política, usa el modo Content-Security-Policy-Report-Only para probar:

Content-Security-Policy-Report-Only: script-src 'nonce-aB3dE9xZ1k' 'strict-dynamic'; report-uri /api/csp-report

El navegador reporta las violaciones sin bloquear nada. Así descubres los casos límite antes de que tus usuarios se topen con scripts bloqueados.

Configurar un endpoint de reportes en Next.js

// app/api/csp-report/route.ts
import { NextRequest } from 'next/server';

export async function POST(request: NextRequest) {
  try {
    const report = await request.json();

    // Registra la violación
    console.warn('[CSP Violation]', {
      'blocked-uri': report['csp-report']?.['blocked-uri'],
      'violated-directive': report['csp-report']?.['violated-directive'],
      'source-file': report['csp-report']?.['source-file'],
      'line-number': report['csp-report']?.['line-number'],
      'user-agent': request.headers.get('user-agent'),
      timestamp: new Date().toISOString(),
    });

    // Envía a tu servicio de registro (Sentry, Datadog, etc.)
    // await logToService('csp-violation', report);

    return Response.json({ status: 'ok' });
  } catch (error) {
    return Response.json({ status: 'error' }, { status: 400 });
  }
}

Uso de Report-To (alternativa moderna)

La directiva más reciente report-to funciona con la Reporting API y es más eficiente que report-uri:

Content-Security-Policy: script-src 'nonce-aB3dE9xZ1k' 'strict-dynamic'; report-to csp-endpoint
Report-To: {"group":"csp-endpoint","max_age":10886400,"endpoints":[{"url":"/api/csp-report"}]}

El soporte es solo de Chrome (v69+) y Edge (v79+), así que usa tanto report-uri (respaldo) como report-to:

Content-Security-Policy: ...; report-uri /api/csp-report; report-to csp-endpoint

Un middleware de producción completo

Este es un middleware listo para producción que gestiona la generación de nonces, la aplicación de la CSP y los reportes:

// middleware.ts
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

function generateNonce(): string {
  const buffer = new Uint8Array(32);
  crypto.getRandomValues(buffer);
  return btoa(String.fromCharCode(...buffer))
    .replace(/[/+]/g, '_') // base64 seguro para URL
    .slice(0, 32);
}

export function middleware(request: NextRequest) {
  // Omite en desarrollo para compatibilidad con HMR
  if (process.env.NODE_ENV === 'development') {
    return NextResponse.next();
  }

  const nonce = generateNonce();
  const requestHeaders = new Headers(request.headers);
  requestHeaders.set('x-csp-nonce', nonce);

  const response = NextResponse.next({
    request: { headers: requestHeaders },
  });

  // Construye una CSP de nivel producción
  const directives = [
    // Política base
    `base-uri 'self'`,
    `default-src 'self'`,
    `form-action 'self'`,
    `frame-ancestors 'none'`,

    // Scripts: nonce + strict-dynamic
    `script-src 'nonce-${nonce}' 'strict-dynamic'`,

    // Estilos: self + unsafe-inline para estilos React en línea
    `style-src 'self' 'unsafe-inline'`,

    // Imágenes: self + URLs data: para React
    `img-src 'self' data: blob:`,

    // Fuentes
    `font-src 'self' data:`,

    // Conexiones
    `connect-src 'self'`,

    // Workers
    `worker-src 'self' blob:`,

    // Reportes
    `report-uri /api/csp-report`,
  ].join('; ');

  // Establece tanto la cabecera de aplicación como la de solo reporte
  // Inicialmente: usa Report-Only para validar
  // Tras la estabilización: cambia a Content-Security-Policy
  response.headers.set(
    'Content-Security-Policy-Report-Only',
    directives
  );

  return response;
}

export const config = {
  matcher: [
    '/((?!api|_next/static|_next/image|favicon.ico|.*\\.(?:svg|png|jpg|jpeg|gif|webp)$).*)',
  ],
};

Flujo de despliegue:

1. Semana 1: despliega con Content-Security-Policy-Report-Only — monitoriza las violaciones sin romper nada
2. Semana 2: revisa todas las violaciones reportadas, corrige los falsos positivos
3. Semana 3: cambia a Content-Security-Policy (modo de aplicación)
4. Continuamente: mantén activo el endpoint de reportes para detectar regresiones

Errores comunes y soluciones

Error 1: el problema de las extensiones

Las extensiones del navegador pueden inyectar sus propios scripts. Estos scripts pierden su nonce al recargar la página porque el content script de la extensión tiene un contexto de nonce diferente.

Solución: usa 'strict-dynamic' — cuando la extensión de un usuario inyecta un script mediante chrome.scripting.executeScript(), el content script de la extensión es el cargador, y strict-dynamic confía en él. Las extensiones que usan el enfoque world: 'MAIN' de manifest v3 para la inyección de scripts pueden seguir bloqueadas — esto es un comportamiento esperado y correcto.

Error 2: hot module replacement en desarrollo

El HMR inyecta scripts en línea y usa conexiones WebSocket que fallan bajo CSP.

Solución: desactiva la CSP por completo en desarrollo:

if (process.env.NODE_ENV === 'development') {
  return NextResponse.next();
}

Error 3: next/dynamic y carga diferida

Las importaciones dinámicas con next/dynamic crean elementos script nuevos en tiempo de ejecución. Sin strict-dynamic, fallan.

Solución: incluye siempre 'strict-dynamic' en tu script-src cuando uses importaciones dinámicas.

Error 4: modo Draft y Preview de Next.js

El modo Draft y el modo Preview de Next.js usan cookies para la autenticación. Son compatibles con CSP (las cookies no están controladas por la CSP), pero la barra indicadora de preview puede inyectar estilos en línea.

Solución: permite 'unsafe-inline' para style-src, o pasa el nonce al componente de la barra de preview.

Error 5: manejadores de eventos en línea en código heredado

Los manejadores de eventos como onclick="handleClick()" o onerror="callback(this)" son bloqueados por una CSP estricta. Los eventos sintéticos de React (JSX onClick={...}) no dan problemas porque React los adjunta mediante addEventListener en JavaScript de confianza.

Solución: si tienes HTML renderizado en el servidor heredado con manejadores de eventos en línea, migra a addEventListener o envuelve los manejadores en etiquetas script con nonce.

Lista de verificación de auditoría CSP

Usa esta lista al desplegar una CSP en tu aplicación React/Next.js:

• [ ] Nonce generado a partir de una fuente aleatoria criptográficamente segura (Web Crypto API)
• [ ] Nonce regenerado en cada respuesta HTTP (no en caché, no por sesión)
• [ ] 'strict-dynamic' incluido en script-src para importaciones dinámicas
• [ ] base-uri establecido en 'self' (previene la inyección de etiquetas base)
• [ ] form-action establecido en 'self' (previene el form-jacking hacia servidores del atacante)
• [ ] frame-ancestors establecido en 'none' u orígenes específicos (previene clickjacking)
• [ ] Sin 'unsafe-inline' en script-src (usa nonces en su lugar)
• [ ] Uso de eval auditado y eliminado en la medida de lo posible
• [ ] CSP desplegada en modo Report-Only durante al menos una semana antes de aplicarla
• [ ] Endpoint de reportes implementado y monitorizado
• [ ] Todos los scripts de terceros (GA, Stripe, Sentry) probados bajo CSP
• [ ] Entorno de desarrollo excluido de la aplicación de CSP
• [ ] Cabecera CSP validada con CSP Evaluator
• [ ] Estilos en línea gestionados: style-src 'unsafe-inline' o basados en nonces
• [ ] Workers permitidos mediante worker-src 'self' blob: (para Web Workers)
• [ ] Orígenes de conexión en la lista de permitidos para endpoints de API (connect-src 'self' https://api.example.com)
• [ ] Cabecera Report-To configurada junto a report-uri para usuarios de Chrome/Edge

Medir el impacto

¿Contra qué protege realmente una CSP correctamente implementada en una aplicación React?

| Vector de ataque | ¿La bloquea la CSP? | Por qué | |--------------|-----------|-----| | XSS almacenado mediante etiquetas <script> | [V] Bloqueado | El script inyectado no tiene nonce | | XSS reflejado mediante parámetros de URL | [V] Bloqueado | El script inyectado no tiene nonce | | XSS basado en DOM mediante innerHTML | [V] Bloqueado | Los elementos script generados no tienen nonce | | Inyección CSS / exfiltración de datos | [V] Bloqueado (parcial) | style-src bloquea las etiquetas <style> maliciosas | | Inyección de etiquetas base | [V] Bloqueado | base-uri: 'self' previene el secuestro de la base | | Form jacking | [V] Bloqueado | form-action: 'self' mantiene los formularios enviando a tu origen | | Clickjacking mediante iframes | [V] Bloqueado | frame-ancestors: 'none' previene la incrustación | | Contaminación de prototipos → inyección de scripts | [V] Bloqueado | Sin nonce en los scripts inyectados por el atacante | | URLs JavaScript en enlaces | [V] Bloqueado | Las URLs javascript: no son scripts de confianza | | Confusión de tipo MIME | [V] Bloqueado (vía X-Content-Type-Options) | Envía la cabecera nosniff junto a la CSP |

La CSP no protege contra:

• Nonces robados mediante XSS (si el atacante puede leer el DOM, puede leer el nonce)
• Inyección en el lado del servidor (inyección SQL, SSRF, inyección de comandos)
• CSRF (se gestiona con cookies SameSite y tokens CSRF)
• Evasión de autenticación (se gestiona con middleware de autenticación)

Conclusión

La política de seguridad de contenido es el control de seguridad de mayor impacto que puedes implementar para una aplicación React después de la autenticación. Una CSP de nonce + strict-dynamic bloquea la gran mayoría de los vectores de ataque XSS — incluidos los patrones de inyección más comunes que afectan a las aplicaciones React — sin romper los patrones de carga dinámica de los que dependen los frameworks modernos.

Las conclusiones clave:

1. Usa nonces, no listas de permitidos. La CSP basada en nonces con strict-dynamic es el único enfoque que funciona para aplicaciones React modernas sin tener que enumerar cada CDN y dominio de terceros.

2. Despliega primero en modo Report-Only. Un periodo de solo reporte de una semana saca a la luz todas las violaciones antes de que apliques la política, evitando roturas visibles para el usuario.

3. Monitoriza tus reportes. La CSP no es de configurar y olvidar. Las nuevas versiones de librerías, los cambios en scripts de terceros y los errores de desarrollo pueden introducir violaciones. Mantén activo tu endpoint de reportes.

4. No dejes que lo perfecto sea enemigo de lo bueno. Una CSP con 'unsafe-eval' y 'unsafe-inline' para estilos sigue siendo mejor que ninguna CSP. Puedes ir endureciéndola con el tiempo a medida que auditas y eliminas dependencias.

5. Empieza hoy. Implementar CSP en un proyecto greenfield lleva una tarde. Adaptarla a un codebase existente con años de integraciones de terceros lleva semanas. Cuanto antes empieces, más fácil será.

La próxima semana: nos sumergiremos en el OWASP Top 10 para Node.js — los diez riesgos de seguridad más críticos en JavaScript del lado del servidor y cómo prevenir cada uno con patrones prácticos y listos para auditar.