Que es la CSP y como proteger tu WordPress

La CSP o Content Security Policy (Política de Seguridad de Contenidos) es una medida de seguridad web que ayuda a prevenir ataques como Cross-Site Scripting (XSS) y inyección de datos. Básicamente, es una cabecera HTTP que permite a los administradores de un sitio web controlar los recursos (scripts, estilos, imágenes, etc.) que pueden cargarse y ejecutarse en su sitio.

---

¿Qué hace una CSP?

Por ejemplo, con una CSP bien configurada puedes decir:

• «Solo acepta scripts de mi dominio y de https://apis.google.com«
• «No permitas la ejecución de scripts en línea (inline scripts) ni la carga de archivos desde dominios no autorizados»

Esto reduce mucho la superficie de ataque ante posibles inyecciones de código malicioso.

---

❓¿Influye la CSP en PageSpeed Insights?

Directamente, no.
La CSP no afecta directamente la puntuación de rendimiento de PageSpeed Insights porque esta herramienta evalúa factores como:

• Tiempo de carga
• Optimización de imágenes
• Uso de caché
• Bloqueo del renderizado
• Peso del DOM
• Latencia de red, etc.

Sin embargo, indirectamente puede influir de estas maneras:

1. Evita la carga de recursos innecesarios o no deseados, lo cual puede mejorar el rendimiento si la política es estricta.
2. Forzar buenas prácticas como evitar scripts inline puede obligarte a tener un código más limpio y optimizado.
3. En algunas auditorías de mejores prácticas o seguridad, Google Lighthouse (dentro de PageSpeed) puede mencionar la ausencia de CSP como una mejora potencial, pero esto no afecta la puntuación de rendimiento.

---

Conclusión

• ¿Es importante tener CSP? → Sí, por seguridad.
• ¿Mejora PageSpeed Insights? → No en rendimiento, pero sí puede ayudar en prácticas seguras.

Si estás buscando optimizar tu puntuación en PageSpeed, enfócate en cosas como el lazy loading, compresión, minimización de recursos y control de caché. Pero si te interesa la seguridad (como deberías), implementar una buena CSP es una excelente medida.

Los nonces (abreviatura de «number used once») son tokens únicos, generados de forma aleatoria para cada solicitud HTTP, que se usan en una Content Security Policy (CSP) para permitir de forma segura la ejecución de scripts inline (en línea), sin tener que habilitarlos globalmente.

---

🔐 ¿Para qué sirven los nonces en CSP?

Uno de los objetivos principales de una buena CSP es bloquear los scripts inline, ya que estos pueden ser usados por atacantes para inyectar código malicioso (como en ataques XSS). Sin embargo, a veces necesitas ejecutar pequeños scripts inline legítimos (por ejemplo, configuraciones iniciales de tu app). Ahí es donde los nonces ayudan.

---

🛠️ ¿Cómo funcionan?

1. El servidor genera un nonce aleatorio (por ejemplo, "abc123xyz") en cada respuesta.
2. Este nonce se incluye:
   • En la cabecera CSP del servidor, como: cssCopiarEditarContent-Security-Policy: script-src 'self' 'nonce-abc123xyz';
   • Y en cada etiqueta <script> inline que quieras permitir: htmlCopiarEditar<script nonce="abc123xyz"> // script permitido </script>
3. El navegador compara el nonce de cada <script> con el que se definió en la política CSP. Si coinciden, el script se ejecuta. Si no, se bloquea.

---

✅ Ejemplo completo

Encabezado CSP:

Content-Security-Policy: script-src 'self' 'nonce-abc123xyz';

HTML:

<script nonce="abc123xyz">
  console.log("Este script inline es seguro");
</script>

<script>
  console.log("Este script será bloqueado por CSP");
</script>

Solo el primer <script> se ejecutará porque tiene el nonce correcto.

---

⚠️ Consideraciones

• El nonce debe ser generado aleatoriamente en cada petición.
• No se debe reutilizar entre peticiones (por eso no se cachea la página con el mismo HTML + nonce fijo).
• Los nonces no sustituyen una CSP completa, pero son una excelente forma de habilitar inline scripts de manera controlada.
• Si usas frameworks como Express (Node.js) o Django, puedes generar nonces en cada renderizado y colocarlos tanto en el HTML como en las cabeceras.

---

🧠 ¿Por qué usar nonces?

• Te permite mantener una política CSP estricta, bloqueando scripts inline por defecto (unsafe-inline queda fuera).
• Al mismo tiempo, te da flexibilidad para ejecutar scripts legítimos inline.

existen varias herramientas en línea que te permiten analizar y verificar si tu CSP está bien aplicada. Aquí te dejo algunas de las más confiables:

---

🧪 Herramientas para comprobar tu CSP

1. CSP Evaluator (de Google)

• Descripción: Analiza tu política CSP y señala debilidades comunes.
• Qué revisa:
  • Presencia de 'unsafe-inline' o 'unsafe-eval'
  • Falta de script-src
  • Uso de wildcards peligrosos (*)
  • Soporte para nonces o hashes
• Ideal para: Verificar políticas ya implementadas o probar una antes de aplicarla.

---

2. SecurityHeaders.com

• Descripción: Analiza varias cabeceras de seguridad, incluida CSP.
• Qué ofrece:
  • Puntaje de seguridad general (A+ a F)
  • Verifica si la CSP está presente
  • Señala configuraciones inseguras
• Ideal para: Auditar tu sitio completo, no solo CSP.

---

3. Report URI

• Descripción: Servicio que puede recolectar violaciones de CSP en tiempo real.
• Qué hace:
  • Puedes incluir una directiva report-uri o report-to en tu CSP.
  • El sitio recibe informes si alguien intenta cargar contenido no autorizado.
• Ideal para: Supervisión activa y detección de ataques.

---

4. Mozilla Observatory

• Descripción: Escanea sitios web en busca de buenas prácticas de seguridad web.
• Incluye CSP: Sí, junto con otras políticas (HSTS, X-Frame-Options, etc.)
• Ideal para: Obtener un panorama general de la seguridad de tu sitio.

---

✅ Recomendación

Para una revisión rápida y útil:

• Empieza con CSP Evaluator de Google para validar la sintaxis y calidad de tu política CSP.
• Luego usa SecurityHeaders o Mozilla Observatory para tener una evaluación completa.

🔍 Cómo comprobar tu CSP con SecurityHeaders.com

1. Ve a: https://securityheaders.com
2. Introduce tu dominio: https://tuwebwordpress.com
3. Haz clic en «Scan».

---

🔎 Qué buscar en el resultado

• Content-Security-Policy: Debe aparecer como una cabecera presente.
• Si falta, te lo indicará como «Missing».
• Te dará una calificación (A+ a F) y sugerencias sobre:
  • uso de 'unsafe-inline'
  • ausencia de script-src
  • uso excesivo de * (wildcards)
  • uso de nonce o hash para scripts inline

---

Otras herramientas útiles:

✅ CSP Evaluator (de Google)

• Pega tu política CSP directamente y revisa su fortaleza.

✅ Mozilla Observatory

• Proporciona un análisis completo de políticas de seguridad, incluyendo CSP.

Ejemplo de un reporte de SecurityHeaders.com, el mensaje clave es:

---

⚠️ “Ouch, you should work on your security posture immediately”

Esto significa que aunque tu sitio tiene algunas cabeceras importantes presentes, su configuración es probablemente débil, incompleta o mal aplicada. Vamos a analizarlo por partes:

---

🔐 Cabeceras detectadas (esto es positivo)

Ya tienes configuradas estas cabeceras:

Cabecera	¿Qué hace?
Strict-Transport-Security	Obliga a usar HTTPS
Content-Security-Policy	Controla qué contenido se puede cargar
X-Frame-Options	Previene clickjacking
X-Content-Type-Options	Evita detección MIME insegura
Referrer-Policy	Controla el envío del Referer
Permissions-Policy	Restringe APIs sensibles del navegador

Esto indica que estás haciendo un esfuerzo por aplicar seguridad, lo cual ya es mejor que muchos sitios.

---

🚨 ¿Qué está mal?

Aunque las cabeceras están presentes, hay problemas en su configuración. Los más comunes son:

1. CSP débil o insegura
   • ¿Incluyes 'unsafe-inline' o 'unsafe-eval'?
   • ¿Usas comodines como * en script-src o default-src?
   • ¿No usas nonce o hash para scripts inline?
2. Strict-Transport-Security (STS) mal configurada
   • ¿No tienes includeSubDomains ni max-age alto?
   • ¿Falta el flag preload?
3. Permissions-Policy incompleta
   • Si no restringes APIs como camera, geolocation, microphone, etc., es una oportunidad perdida.
4. X-Frame-Options muy permisiva
   • ¿Está configurada como ALLOW-FROM o simplemente falta?

---

✅ Qué hacer ahora

1. Verifica tu CSP actual

Usa CSP Evaluator de Google
Pega ahí tu política Content-Security-Policy actual (desde tu servidor o HTML). Si no sabes cuál es, puedes obtenerla con:

curl -I https://tuwebworpdress.com | grep -i content-security-policy

O, si usas navegador, abre DevTools → pestaña «Network» → selecciona la primera petición → pestaña «Headers».

---

2. Aplica una CSP fuerte y moderna

Ejemplo base segura:

content-Security-Policy:
  default-src 'self';
  script-src 'self' 'nonce-<RANDOM_NONCE>';
  style-src 'self' 'nonce-<RANDOM_NONCE>';
  object-src 'none';
  base-uri 'self';
  frame-ancestors 'none';
  upgrade-insecure-requests;

---

3. Revisa Strict-Transport-Security

Ejemplo recomendado:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

---

4. Mejora Permissions-Policy

Ejemplo recomendado:

Permissions-Policy: camera=(), microphone=(), geolocation=(), fullscreen=(self)

si usas WordPress, hay varios plugins que te permiten gestionar una Content Security Policy (CSP) sin tener que editar archivos del servidor manualmente. A continuación te muestro las mejores opciones y cómo funcionan:

---

🔌 Plugins de WordPress para configurar CSP

1. HTTP Headers

• 🔹 Muy completo y fácil de usar
• 🔹 Permite configurar:
  • Content-Security-Policy
  • Strict-Transport-Security
  • X-Frame-Options
  • Permissions-Policy, etc.
• 🔧 Desde el panel de administración puedes copiar/pegar una política CSP o construirla por partes.
• 🧠 Te permite activar modo «report-only» para pruebas seguras.

📌 Plugin en WordPress.org

---

2. Security Headers (por WPManageNinja)

• 🔸 Más simple, pero incluye CSP básica
• 🔸 Puedes activar/desactivar directivas comunes de seguridad
• ⚠️ No tiene constructor avanzado de políticas (menos personalizable)

📌 Plugin en WordPress.org

---

3. WP CSP (poco actualizado, pero funcional)

• 🧪 Permite definir una política CSP específica directamente
• 🚧 Requiere que tengas cierta experiencia con las directivas CSP
• ⚠️ Puede no estar bien mantenido en versiones recientes de WP

📌 WP CSP Plugin

---

🛠️ Recomendación para ti

Para un sitio como el tuyo, lo mejor es:

✅ Instalar «HTTP Headers»

1. Ve a Plugins > Añadir nuevo
2. Busca «HTTP Headers»
3. Instálalo y actívalo
4. Ve a Ajustes > HTTP Headers
5. Activa la opción de Content-Security-Policy
6. Añade una política segura, por ejemplo:

default-src 'self'; script-src 'self'; style-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'; upgrade-insecure-requests;

🧪 Consejo: Empieza con el modo «report-only» para ver si rompe funcionalidades antes de forzarlo.

---

Si quieres generar una política CSP personalizada para tu sitio WordPress (según los scripts, fuentes, etc.)? Solo debes tener en cuenta si usas cosas como:

• Google Fonts
• Google Analytics
• YouTube
• Elementor o algún builder específico

Con todo eso ya se puede armar una lista para pegar en el plugin.

Las APIs externas como las de Google Search Console y OpenAI sí influyen en la CSP, porque estás cargando o enviando datos a dominios que no pertenecen a tu propio sitio (self), y eso debe permitirse explícitamente en tu política CSP. De lo contrario, el navegador podría bloquear las solicitudes.

---

❓ Uso APIs de Search console y de Openai, ¿influye en la CSP?

🧠 ¿Cómo afecta esto?

Depende de cómo usas las APIs:

1. Si usas JavaScript del lado del cliente (frontend):

• Tendrás que permitir las solicitudes fetch/XHR a dominios externos como:
  • https://www.googleapis.com/
  • https://api.openai.com/

2. Si las llamadas a las APIs se hacen del lado del servidor (PHP en WordPress):

• No necesitas agregarlas a CSP, ya que el navegador nunca las ve.

---

✅ Ejemplo de CSP adaptado

Supongamos que:

• Usas fetch() o axios en el navegador para acceder a OpenAI o Search Console
• Usas fuentes propias (nada de Google Fonts)
• No necesitas inline scripts ni estilos

Puedes usar esta política CSP:

default-src 'self';
script-src 'self';
style-src 'self';
connect-src 'self' https://api.openai.com https://www.googleapis.com;
img-src 'self' data:;
object-src 'none';
base-uri 'self';
frame-ancestors 'none';
upgrade-insecure-requests;

Explicación:

• connect-src: permite llamadas AJAX/fetch/WebSocket
• img-src: permite imágenes locales y data: (útil para SVG inline codificados en base64)
• object-src 'none': bloquea Flash y otros objetos embebidos (buena práctica)

---

🧪 Si usas CSP en modo report-only

Puedes probar sin romper nada con:

Content-Security-Policy-Report-Only: ...

De esta forma, ves en la consola del navegador (o en report-uri si lo configuras) qué se bloquearía, sin bloquearlo realmente.

---

🧩 ¿Cómo saber si necesitas connect-src?

Abre las herramientas de desarrollador (F12 → pestaña «Network») y mira si se hacen llamadas desde el navegador a:

• api.openai.com
• www.googleapis.com

Si es así → necesitas esos dominios en connect-src.
Si no → probablemente las llamadas se hacen desde el backend y no necesitas agregarlos.

---

¿Quieres que revisar una política exacta para tu sitio (según tu HTML y JS)? Si tienes acceso al HTML, o haces una lista de:

• Scripts externos que cargas
• Servicios API que usas desde el navegador
  Con eso ya podrias tener una CSP personalizada y lista para pegar en el plugin.

.

❓Si tengo una tienda Woocommerce, ¿influye en la CSP que debo aplicar?

Sí, tener una tienda WooCommerce influye bastante en la política CSP que debes aplicar, porque WooCommerce y sus extensiones suelen cargar scripts, estilos, fuentes y llamadas a servidores externos que deben permitirse explícitamente.

Una CSP muy estricta puede romper funcionalidades clave de tu tienda, como:

• Carritos dinámicos (AJAX)
• Checkout (formularios con JavaScript)
• Gateways de pago (como Stripe, PayPal)
• Widgets de terceros (por ejemplo, chats, Google reCAPTCHA, etc.)

---

🧠 ¿Qué cosas suelen requerir permisos especiales en CSP con WooCommerce?

1. AJAX de WordPress/WooCommerce

• Necesitas permitir admin-ajax.php y llamadas a tu propio dominio: plaintextCopiarEditarconnect-src 'self';

2. Pasarelas de pago

• Stripe → https://js.stripe.com, https://api.stripe.com
• PayPal → https://www.paypal.com, https://*.paypal.com

3. Google reCAPTCHA (si lo usas)

• https://www.google.com
• https://www.gstatic.com

4. Google Fonts (si los usas en tu tema)

• https://fonts.googleapis.com
• https://fonts.gstatic.com

5. Imágenes de productos y CDN

• Si usas imágenes externas o un CDN (Cloudflare, Bunny, etc.), hay que permitirlo en img-src

---

✅ Ejemplo de CSP adaptable para WooCommerce

default-src 'self';
script-src 'self' https://js.stripe.com https://www.google.com https://www.gstatic.com;
style-src 'self' 'unsafe-inline' https://fonts.googleapis.com;
font-src 'self' https://fonts.gstatic.com;
connect-src 'self' https://api.stripe.com https://www.paypal.com https://www.googleapis.com https://api.openai.com;
img-src 'self' data:;
object-src 'none';
base-uri 'self';
frame-ancestors 'none';
frame-src https://www.paypal.com https://js.stripe.com https://www.google.com;
upgrade-insecure-requests;

🧪 Empieza siempre en modo Content-Security-Policy-Report-Only si no estás seguro. Así puedes monitorear qué se bloquearía sin romper tu tienda.

---

🛠 Recomendaciones prácticas

1. Instala el plugin HTTP Headers que mencionamos antes.
2. Usa una CSP flexible al principio y ve endureciéndola si todo sigue funcionando.
3. Si usas servicios como Stripe o PayPal, consulta su documentación oficial de CSP:
   • Stripe: https://stripe.com/docs/security
   • PayPal: https://developer.paypal.com

---

Si quieres preparar una CSP a medida basada en los plugins y servicios activos de tu tienda, debes tener en cuenta:

• Qué pasarelas de pago usas
• Si usas Google Fonts o reCAPTCHA
• Si usas scripts personalizados, analytics, etc.

Y ya puedes la preparar la CSP lista para implementar.

Como puedes ver implementar una CSP puede ser algo complejo, pero muy útil para asegurar la seguridad de tu WordPress. Te recomendamos encarecidamente que lo planifique si no quieres dolores de cabeza. Es un servicio que nosotros proporcionamos como Expertos en WordPress para que tengan sus tiendas WooCommerce y Blogs WP seguros ante ataques maliciosos en red.