---
title: Política de seguridad de contenido (CSP)
canonical: https://wpsecurityninja.com/docs/security-fixes/politica-seguridad-contenido-csp/
---
Content Security Policy (CSP) es una cabecera de respuesta HTTP que indica al navegador qué fuentes pueden cargar scripts, estilos, imágenes, frames y otros recursos. Usada con cuidado, limita lo que puede hacer el código inyectado. Usada sin cuidado, rompe Analytics, fuentes, incrustaciones y la administración de WordPress.

Security Ninja Pro puede establecer cabeceras relacionadas desde **Security Ninja → Correcciones**. Prefiere el modo solo de informe mientras ajustas una política. Consulta también [Cabeceras de seguridad](https://wpsecurityninja.com/es/docs/security-fixes/cabeceras-de-seguridad/).

## Por qué los sitios WordPress usan CSP

Una página WordPress típica carga recursos del tema, plugins, CDN, fuentes y analítica. Sin CSP, el navegador ejecutará JavaScript inyectado igual que scripts legítimos. CSP no corrige todos los fallos de plugins, pero sube el listón tras una inyección.

## Cómo funciona CSP

Una política básica:

```text
Content-Security-Policy: script-src 'self'
```

Eso permite scripts solo desde tu propio origen. Los scripts externos o inyectados se bloquean (o se informan, en modo solo de informe).

## Directivas útiles

<dl class="docs-term-list">
<dt><code>default-src</code></dt>
<dd>Reserva para tipos de recurso que no hayas listado</dd>
<dt><code>script-src</code></dt>
<dd>Fuentes de JavaScript permitidas</dd>
<dt><code>style-src</code></dt>
<dd>Fuentes de CSS permitidas</dd>
<dt><code>img-src</code></dt>
<dd>Fuentes de imágenes permitidas</dd>
<dt><code>font-src</code></dt>
<dd>Fuentes de tipografías permitidas</dd>
<dt><code>connect-src</code></dt>
<dd>AJAX, fetch, WebSocket, EventSource</dd>
<dt><code>frame-src</code></dt>
<dd>Frames incrustados (YouTube, mapas, widgets de pago)</dd>
<dt><code>object-src</code></dt>
<dd>Plugins como Flash; normalmente <code>'none'</code></dd>
<dt><code>form-action</code></dt>
<dd>Destinos permitidos de envío de formularios</dd>
<dt><code>frame-ancestors</code></dt>
<dd>Quién puede incrustar tus páginas (relacionado con clickjacking)</dd>
<dt><code>report-uri</code> / APIs de informe</dt>
<dd>Dónde envían los navegadores informes de violación</dd>
</dl>

## Ejemplos de políticas

**Línea base solo HTTPS (control XSS débil):**

```text
Content-Security-Policy: default-src https:
```

**Lista de permitidos de CDN habituales (suele necesitar más ajuste):**

```text
Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.jsdelivr.net https://cdnjs.cloudflare.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data:;
```

**Punto de partida estricto (romperá muchos sitios WordPress hasta que añadas fuentes):**

```text
Content-Security-Policy: default-src 'none'; script-src 'self'; style-src 'self'; img-src 'self'; font-src 'self'; connect-src 'self'; frame-ancestors 'none'; base-uri 'self'; form-action 'self';
```

## Palabras clave

<dl class="docs-term-list">
<dt><code>'none'</code></dt>
<dd>Bloquea todo ese tipo</dd>
<dt><code>'self'</code></dt>
<dd>Mismo origen (no todos los subdominios)</dd>
<dt><code>'unsafe-inline'</code></dt>
<dd>Permite script/estilo en línea; debilita CSP</dd>
<dt><code>'unsafe-eval'</code></dt>
<dd>Permite APIs tipo <code>eval()</code>; debilita CSP</dd>
</dl>

Prefiere nonces o hashes frente a `'unsafe-inline'` cuando puedas. Muchos plugins de WordPress siguen necesitando excepciones temporales.

## Prueba antes de aplicar

Usa primero el modo solo de informe:

```text
Content-Security-Policy-Report-Only: default-src 'self'; report-uri https://tusitio.com/csp-report
```

Puedes enviar una cabecera de aplicación y otra solo de informe a la vez mientras pruebas una política más estricta. No confíes ciegamente en los payloads de informes de violación; limita la tasa de cualquier endpoint que los acepte.

## Problemas específicos de WordPress

* **Scripts y estilos en línea** en temas y plugins suelen necesitar `'unsafe-inline'`, nonces o refactorización.
* **Servicios de terceros** (Analytics, fuentes, chat, anuncios) necesitan entradas explícitas en la lista de permitidos.
* **wp-admin** usa muchos scripts en línea. Considera una política más laxa para URLs de administración que para el sitio público.
* **Incrustaciones de YouTube / mapas** necesitan `frame-src` (y a veces ajustes de Referrer-Policy). Consulta [Error 153 de YouTube](https://wpsecurityninja.com/es/docs/errors-and-debugging/solucionar-error-153-embeds-youtube/) (documentación en inglés).

Fragmentos de ejemplo para listas de permitidos:

```text
script-src https://www.google-analytics.com
font-src https://fonts.gstatic.com
style-src https://fonts.googleapis.com
frame-src https://www.youtube.com
```

## Cómo añadir la cabecera

**Apache (`.htaccess`):**

```apache
Header set Content-Security-Policy "default-src 'self';"
```

**Tema o plugin pequeño:**

```php
add_action(
	'send_headers',
	function () {
		header( "Content-Security-Policy: default-src 'self';" );
	}
);
```

**Security Ninja Pro:** activa y ajusta opciones relacionadas con CSP en **Security Ninja → Correcciones**.

## Lista de comprobación práctica

1. Empieza en modo solo de informe.
2. Observa la consola del navegador y los informes de violación.
3. Añade solo las fuentes que necesites.
4. Evita comodines amplios como `https://*`.
5. Incluye `data:` en `img-src` si tu tema usa URIs data.
6. Vuelve a probar tras instalar o actualizar plugins.
7. Mantén CSP como una capa. Las actualizaciones, autenticación fuerte y el firewall siguen importando.

## Más lectura

* [Introducción a CSP de Scott Helme](https://scotthelme.co.uk/content-security-policy-an-introduction/)
* [Cabeceras de seguridad en Security Ninja](https://wpsecurityninja.com/es/docs/security-fixes/cabeceras-de-seguridad/)