Ámbitos de red y de programa
Acotar a qué dominios se puede hablar y qué programas se pueden lanzar. Las trampas de cada uno —el subdominio comodín, la redirección, el argumento que se convierte en comando— y por qué los dos suelen sobrar.
Ámbito de red
{ "identifier": "http:default", "allow": [{ "url": "https://api.ejemplo.dev/*" }], "deny": [{ "url": "https://api.ejemplo.dev/admin/*" }]}Y sus tres trampas:
La tercera es la decisiva: un ámbito de red que el frontend puede esquivar con una petición normal no está acotando nada. Si la política de contenido está abierta, este ámbito es decorativo.
Ámbito de programa
{ "identifier": "shell:allow-execute", "allow": [ { "name": "convertir", "cmd": "ffmpeg", "args": ["-i", { "validator": "\\S+" }, "salida.mp4"] } ]}Es más estricto que el de red —hay que declarar el programa y la forma de sus argumentos— y su trampa es peor:
Un argumento puede convertirse en un comando. Muchas herramientas de línea de comandos aceptan opciones que cambian lo que hacen: escribir en un fichero, cargar una configuración, ejecutar otra cosa. Un validador que acepte cualquier cadena sin espacios deja pasar una opción, y esa opción puede ser exactamente la que convierte una conversión de vídeo en una escritura arbitraria.
Las tres reglas:
- Valida la forma de cada argumento, y valida estrecho: si es un nombre de fichero, que el validador solo acepte nombres de fichero.
- Nunca aceptes un argumento libre. Un validador que acepte cualquier cosa es no tener validador.
- Y prefiere argumentos fijos. Si la operación siempre usa las mismas opciones, ponlas en el ámbito y deja variable solo lo que de verdad varía.
Por qué los dos suelen sobrar
Aquí está el argumento del nivel, y es el mismo del 14.4 aplicado a estos dos plugins:
La conclusión práctica: si tu capability concede el plugin de red o el de shell al frontend, la pregunta antes de escribir el ámbito es si esa operación debería ser un comando propio. Casi siempre sí, y entonces el ámbito no hace falta porque el permiso tampoco.
Cuándo sí hacen falta
Tres casos legítimos, para no caer en el dogma:
El plugin que abre una URL en el navegador del sistema. No es una petición: es entregarle un enlace al sistema operativo. Ahí un ámbito de dominio tiene sentido y es lo correcto — acotado a tu documentación y poco más.
Un prototipo. Mientras se explora, conceder el plugin de red con un ámbito estrecho es más rápido que escribir comandos. Con la marca de temporal del nivel 26.5.
Una aplicación cuyo dominio es hacer peticiones. Un cliente de API, una herramienta de pruebas. Ahí el frontend hace peticiones porque eso es el producto, y el ámbito es la defensa que hay.