app.security: la política de contenido y sus vecinos

La sección

Qué hace una política de contenido aquí

Es la misma que en la web: una lista de dónde puede venir cada tipo de recurso, aplicada por el motor. Si tu página intenta cargar un script de un dominio que la política no autoriza, el motor lo bloquea y lo dice en la consola.

Lo que cambia en una aplicación de escritorio es el modelo de amenaza, y merece precisarlo porque no es obvio: aquí no hay un servidor ajeno sirviendo tu página. Tu HTML lo pusiste tú. Entonces, ¿contra qué protege?

Contra tres cosas concretas:

• Contra tus dependencias. Un paquete comprometido en tu frontend que intente conectar con un servidor propio se encuentra la política delante. Es la protección más valiosa de las tres, y la más olvidada.
• Contra el contenido que muestres. Si tu aplicación pinta datos de fuera —un archivo del usuario, una respuesta de una API, un texto en formato enriquecido— y en algún punto eso acaba interpretado como HTML, la política limita lo que ese HTML puede hacer.
• Contra ti mismo dentro de un año. Una política estricta convierte «alguien añadió un script de analítica de terceros» en un fallo visible en desarrollo, en vez de en una decisión que nadie revisó.

Escribirla desde el principio, no al final

La política inicial que conviene poner el primer día es la más estricta que deje funcionar la aplicación:

"csp": "default-src 'self'; connect-src 'self' ipc: http://ipc.localhost"

Y a partir de ahí se relaja solo cuando algo se rompa, y con la directiva concreta. La consola dice exactamente qué se ha bloqueado y por qué directiva, así que el bucle es corto: se rompe, se lee, se añade lo mínimo.

El orden importa mucho más de lo que parece. Empezar estricto y relajar te deja una política que refleja lo que la aplicación necesita de verdad. Empezar sin política y apretar al final te deja delante de una interfaz entera funcionando, sin saber qué depende de qué, y el resultado casi siempre es una política tan ancha que no protege de nada.

Las claves que avisan en el nombre

Es una convención del framework que conviene reconocer: cualquier clave que empiece por dangerous está ahí para un caso raro y documentado, no para desbloquear un problema.

Cuando aparezca la tentación de poner una en true, la pregunta útil no es «¿qué desactiva?» sino «¿por qué el framework la está corrigiendo?». La respuesta casi siempre señala el arreglo de verdad, que está en otro sitio.

La fase V vuelve sobre cada una con su caso legítimo. Hasta entonces, la regla es no tocarlas.

Y una que no está aquí

app.security tiene también una clave para declarar capabilities en línea, dentro del propio fichero de configuración. Funciona, y no es donde conviene escribirlas: los permisos van en el directorio capabilities/, en ficheros separados por funcionalidad, precisamente para que un cambio de permisos aparezca en el diff como un cambio de permisos y no perdido dentro de una edición de configuración.

Es una diferencia de forma, no de comportamiento, y es de las que deciden si un proyecto se puede auditar en dos años. Fase V.