# Política HTTP y límites del host

Configurar cabeceras, CSP, orígenes y publicación sin confundirlas con permisos del runtime.

Consulta las versiones, cambios y requisitos en [Framework 4.0 y CLI 1.2](/es/docs/guides/releases/).


<span class="section-anchor" id="section-1"></span>

## Dos controles con responsabilidades distintas

`security` en `wu.config.json` define la política HTTP que sirve WU y que el build exporta para otros hosts. Los `grants` de cada app forman parte de la autoridad que el host entrega al runtime. Una cabecera CSP no sustituye el contrato de capacidades, y un grant no autoriza por sí solo al navegador a cargar un origen bloqueado por CSP.

<span class="section-anchor" id="section-2"></span>

## Configuración

```json
{
  "security": {
    "enabled": true,
    "csp": "",
    "frame_options": "DENY",
    "referrer_policy": "strict-origin-when-cross-origin",
    "nosniff": true,
    "app_origins": ["https://apps.example.com"],
    "connect_origins": ["https://api.example.com"],
    "wasm": false
  }
}
```

Los dominios del ejemplo son marcadores de posición. La política debe describir los orígenes que tu aplicación realmente utiliza.

| Campo | Efecto |
| --- | --- |
| `enabled` | Activa o desactiva el conjunto de cabeceras |
| `csp` | Política generada, literal, `report-only` u `off` |
| `frame_options` | `X-Frame-Options`; defecto `DENY` |
| `referrer_policy` | Política de referencia |
| `permissions_policy` | Capacidades del navegador por Permissions-Policy |
| `hsts` | Strict-Transport-Security; útil al servir mediante TLS |
| `nosniff` | `X-Content-Type-Options: nosniff` |
| `corsOrigin` o `cors` | Origen CORS; `cors` también admite un objeto con `origin` |
| `app_origins` | Orígenes de bundles: script y conexiones |
| `connect_origins` | Orígenes de API: conexiones |
| `wasm` | Permite compilación WASM en la CSP generada |

El parser también contempla grafías camelCase para varios campos, como `appOrigins`, `connectOrigins`, `frameOptions` y `wasmUnsafeEval`. Para CORS hay una excepción importante: `cors_origin` es el nombre interno de la estructura, pero el JSON acepta `corsOrigin` o `cors`, no esa grafía snake_case.

<span class="section-anchor" id="section-3"></span>

## Convenciones de valores

Para los campos de cabecera de texto, una cadena vacía deja decidir a WU y `off` suprime esa cabecera. `csp: "report-only"` genera una política equivalente en la cabecera de reporte; el navegador informa infracciones sin bloquearlas por esa política. Una cadena CSP literal se utiliza tal cual.

La generación analiza los scripts inline del documento final y calcula hashes. Hace falta ejecutarla después de cualquier inserción de catálogo o import map. Introducir un handler HTML como `onclick` tiene un tratamiento diferente de un script con hash; los diagnósticos señalan incompatibilidades. Mantener eventos en módulos y estilos en hojas evita depender de excepciones del HTML.

En 1.2.0, los hashes CSP se calculan por página y normalizan saltos CRLF. `security.upgradeInsecureRequests` permite controlar la promoción a HTTPS. El build conserva `_headers` del shell, aplica caché inmutable a archivos con hash y valida valores para impedir inyección de cabeceras. Revisa la política realmente enviada por el hosting con `wu doctor --url`.

<span class="section-anchor" id="section-4"></span>

## CORS

No se emite `Access-Control-Allow-Origin` por defecto. Para servir microapps desde el mismo origen no hace falta habilitar `*`. Cuando la topología exige un origen distinto, configura el valor concreto y revisa también CSP, credenciales y la política del destino.

La opción `cors` de una regla de proxy pertenece a esa regla. No es idéntica a `security.corsOrigin`, que gobierna las respuestas del servidor de producción.

<span class="section-anchor" id="section-5"></span>

## Archivos publicables

La seguridad de rutas decodifica escapes antes de comprobar segmentos y rechaza traversal, controles, barras invertidas y paths absolutos. El filtro de archivos bloquea dotfiles y extensiones o nombres considerados sensibles. `.well-known` es una excepción deliberada porque contiene documentos públicos de protocolo.

El build y `doctor` revisan áreas publicables, pero el lugar correcto de una credencial sigue siendo el backend o su entorno. Si una aplicación necesita un token privado, no debe incorporarlo a sus fuentes o a `public/`, aunque un nombre concreto no figure en la lista de bloqueos.

El servidor de desarrollo aplica su propia política de Host, CORS, HMR y acceso a archivos, incluso para sourcemaps, módulos y query imports. Configura túneles mediante `dev.allowedHosts`; solo `VITE_*` y `WU_*` de `.env` llegan al navegador. Consulta [desarrollo](/es/docs/cli/development/) para migrar estos comportamientos.

<span class="section-anchor" id="section-6"></span>

## Sentinel

La instancia del sentinel está desactivada en `wu dev` y se instancia con sus valores predeterminados en `wu serve`. Hay código para clasificar solicitudes y publicar rutas de protocolo ACP. La existencia de esos módulos no acredita protección universal frente a automatización ni reemplaza control de acceso del producto.

CLI `1.2.0` acepta `manifest: "define"` en cada app y `security.frameOrigins` para los iframes remotos. Los orígenes de frames solo entran en `frame-src`; no habilitan scripts ni conexiones del host. El filtro de navegación de catálogos no bloquea su lectura por fetch. Consulta [apps remotas](/es/docs/framework/remote-apps/) y [build](/es/docs/cli/build/).

<span class="section-anchor" id="section-7"></span>

## Referencia de implementación

- `wu-cli/src/config/config.zig`
- `wu-cli/src/runtime/security.zig`
- `wu-cli/src/runtime/project_fs.zig`
- `wu-cli/src/runtime/allowed_hosts.zig`
- `wu-cli/src/runtime/dev/env.zig`
- `wu-cli/tests/dev-security.test.cjs`
- `wu-cli/tests/doctor-policy.test.cjs`