Simon Willison construye un sandbox con lista blanca dinámica de CSP

Un iframe protegido con Content Security Policy suele ser un callejón sin salida para el desarrollador: la petición bloqueada aparece en la consola, y la única solución es modificar la cabecera CSP a mano y recargar. Simon Willison publicó el 13 de mayo una herramienta experimental que cambia ese flujo por completo, interceptando los errores antes de que lleguen al vacío y ofreciendo al usuario la opción de añadir el dominio bloqueado a una lista blanca en ese mismo momento.

El resultado práctico es llamativo: puedes cargar una aplicación arbitraria dentro de un iframe con `default-src 'none'`, intentar hacer una llamada a `https://api.inaturalist.org` (o cualquier otro dominio), recibir un modal que pregunta si quieres permitir ese origen, aceptar, y ver cómo la página se recarga con la CSP ampliada. Todo sin tocar un fichero de configuración.

Cómo funciona el mecanismo

La clave está en una versión personalizada de `fetch()` que se inyecta en el iframe protegido. Cuando una petición es bloqueada por la CSP, ese `fetch()` captura el error y lo comunica al documento padre mediante `postMessage`. El padre, que sí tiene acceso completo al estado de la aplicación, muestra el diálogo de confirmación. Si el usuario acepta, el dominio se añade a una lista blanca persistida en memoria y la página se refresca con una CSP nueva que incluye ese origen en `connect-src`.

Este patrón se apoya en una investigación previa que Willison documentó a principios de abril, donde exploraba cómo escapar de manera controlada de un iframe con CSP para comunicarse con el documento padre. La herramienta publicada esta semana es la aplicación práctica de ese experimento.

Puedes probarla directamente en tools.simonwillison.net/csp-allow, donde hay un editor de HTML en el panel izquierdo y una vista previa en el panel derecho, con botones para resetear el ejemplo, limpiar la lista blanca y refrescar el preview.

Por qué es relevante para entornos de ejecución de código

Este tipo de sandbox con CSP dinámica tiene aplicación directa en herramientas de ejecución de código en el navegador, entornos de previsualización tipo CodePen o sistemas donde un agente de IA genera código HTML/JS que luego se ejecuta de forma aislada. El problema clásico en estos contextos es que el desarrollador que construye el sandbox no sabe de antemano qué APIs externas va a necesitar el código generado.

Con este enfoque, la lista blanca deja de ser una decisión de diseño anticipada y pasa a ser una decisión de usuario en tiempo de ejecución. El sandbox sigue siendo estricto por defecto; solo se abre cuando el usuario lo autoriza explícitamente, dominio a dominio.

La nota original de Simon Willison no menciona integración con ningún LLM en particular, aunque la utilidad encaja de manera natural en flujos donde Claude u otro modelo genera aplicaciones web que luego se ejecutan en previsualización inmediata.

Limitaciones que el propio experimento reconoce

El enfoque tiene bordes sin pulir. La lista blanca vive en memoria del documento padre, por lo que no persiste entre sesiones salvo que se implemente almacenamiento adicional. Además, el mecanismo de interceptación depende de que el `fetch()` personalizado cubra todos los tipos de petición bloqueables por CSP: imágenes, scripts, workers o WebSockets tienen rutas de bloqueo distintas que un simple wrapper de `fetch()` no necesariamente captura.

Es un experimento, no una librería lista para producción. Willison lo presenta con esa honestidad, lo cual es precisamente lo que lo hace útil como punto de partida para quien quiera construir algo más robusto sobre esta base.

---

Opinión EP: La aproximación es elegante porque no debilita la CSP por defecto, sino que la hace negociable con el usuario en lugar de ignorarla. Para equipos que están construyendo entornos de previsualización de código generado por agentes, merece al menos un prototipo de evaluación.