Deno Permissions: Locking Down File and Network Access

Why Permissions Matter in Deno

Deno’s default‑deny policy means every script starts with no access to the file system, network, environment, or subprocesses. Only explicit grants change that. This built‑in sandbox protects against accidental data leaks or malicious code.

Permission Flags – The Opt‑In Approach

When you launch a script, you pass flags that describe what the script can touch:

deno run --allow-read=/tmp/test.txt --allow-net=api.example.com script.ts

• --allow-read – read access to files or directories. Scopes can be a single file, a directory, or a glob pattern.
• --allow-net – network access. You can limit by hostname or port, e.g., --allow-net=api.example.com:443.
• --allow-env – read selected environment variables.
• Other flags: --allow-write, --allow-run, --allow-hrtime, etc.

Without a flag, any attempt to use the protected resource throws PermissionDenied and the script aborts.

Fine‑Grained Control: Scoping Permissions

Granularity is key. The following command allows a script to read only /tmp/test.txt and nothing else:

deno run --allow-read=/tmp/test.txt script.ts

Running node script.js that tries to open /etc/passwd would succeed, but the same Deno command would fail with:

PermissionDenied: Permission denied: open "/etc/passwd"

Similarly, --allow-net=api.example.com permits network requests only to that host. Attempts to reach google.com will be blocked.

Runtime Permission Requests

Deno also supports dynamic permission prompts. Inside a script you can call:

const granted = await Deno.requestPermission("net");
if (granted) {
  // proceed with fetch
}

This will pause execution and ask the user to allow or deny the request. Once granted, the permission stays cached for the life of the process unless you explicitly revoke it:

await Deno.requestPermission("net", "revoke");

Trade‑Offs and Limitations

• Process‑Wide Flags – A flag applies to the entire process. A single --allow-read can expose many files if you’re not careful with scoping.
• Interactive Prompts – Dynamic requests block execution until user input, which can hurt CLI tool performance or automation scripts.
• No Per‑File Runtime Flags – Permissions are set before the script starts; you can’t grant different rights to different files within the same script.
• Environment Variables – --allow-env only allows reading, not writing. To read a secret, you must list it explicitly.

Practical Test: Verify Permissions Work

1. Create a test file:

   echo "Hello" > /tmp/test.txt
   

2. Write a script read.ts that reads both /tmp/test.txt and /etc/passwd:

   const txt = await Deno.readTextFile("/tmp/test.txt");
   console.log("test.txt:", txt);
   const passwd = await Deno.readTextFile("/etc/passwd");
   console.log("/etc/passwd:", passwd);
   

3. Run with scoped read permission:

   deno run --allow-read=/tmp/test.txt read.ts
   

   • Output: the content of test.txt is printed.
   • Attempting to read /etc/passwd throws PermissionDenied.
4. Test network scoping: create fetch.ts that fetches https://api.example.com and https://google.com. Run:

   deno run --allow-net=api.example.com fetch.ts
   

   • Connection to api.example.com succeeds.
   • Connection to google.com fails with PermissionDenied.
5. Test dynamic request: modify fetch.ts to call Deno.requestPermission("net") before the second fetch. Observe the prompt and verify that the second request succeeds after granting.

Actionable Takeaway

Adopt Deno’s permission system in your projects to enforce least‑privilege access. Start by running all scripts with the most restrictive flags you can, then incrementally widen permissions only when necessary. Use the command‑line flags for CI pipelines and the runtime request API for interactive tools. Verify each permission change with the test steps above to ensure your security posture remains tight.