Lo que este modelo no protege
Las capabilities acotan una frontera y solo una. Las seis cosas que quedan fuera, por qué conviene saberlo, y contra cuál de ellas sí se puede hacer algo.
Las seis
Las dos que sí se pueden atacar hoy
De las seis, dos tienen una defensa concreta que se puede montar esta semana y suele faltar:
La quinta: la política de contenido. Es la que más devuelve y la que la plantilla deja desactivada —nivel 7.4—. Sin ella, todo el trabajo de las capabilities protege una puerta mientras la ventana está abierta: un atacante en tu webview no necesita comandos para sacar datos, le basta una petición a un servidor suyo. Es el complemento obligatorio de la fase V, no un extra.
La segunda: las dependencias del core. No hay mecanismo, y sí hay una decisión: que el core tenga pocas y que entren revisadas. Nivel 26.2.
Las otras cuatro se cubren con revisión, con firma, o no se cubren, y saberlo evita gastar tiempo donde no toca.
Los dos síntomas de la falsa confianza
«Está en el core, así que es seguro». Poner algo en Rust no lo hace seguro: lo hace inalcanzable desde la webview salvo por un comando. Si el comando existe y está concedido, la frontera no protege nada. Lo que protege es que el comando exprese una operación acotada —nivel 14.4—, no dónde está escrito.
«Tenemos capabilities, así que estamos cubiertos». Cubre una frontera. Si tu política de contenido está en null, si el core arrastra ochenta dependencias sin revisar, o si un comando acepta una ruta arbitraria, las capabilities están perfectamente configuradas alrededor de un agujero.