rules-deno

RISK: --allow-all (-A) grants the Deno script unrestricted access to the filesystem, network, environment, subprocess execution, and FFI — it completely defeats Deno's security model. FIX: Grant only the specific permissions needed (--allow-net=api.example.com, --allow-read=./data, etc.).

RISK: Interpolating variables into Deno.Command arguments enables command injection — if the value is user-controlled, an attacker can execute arbitrary host commands. FIX: Always pass command arguments as explicit string literals or a validated allowlist; never build command strings by concatenation.

Deno.Buffer is removed. Use the WHATWG Streams API (ReadableStream/WritableStream) or Buffer from the Deno standard library (https://deno.land/std/io/buffer.ts) instead.

RISK: Dynamic imports from user-supplied or runtime-assembled URLs allow loading and executing untrusted remote code, bypassing the lock file and integrity checks. FIX: Import from locked URLs declared in deno.json/deno.lock; if dynamic imports are required, validate against an explicit allowlist of trusted origins.

RISK: eval() and new Function() execute arbitrary strings as code. In Deno, this also circumvents the permission model — even without --allow-run, eval can perform operations within the already-granted permissions. FIX: Avoid eval entirely; use explicit logic, JSON.parse() for data, or a sandboxed interpreter if dynamic evaluation is required.

RISK: Hardcoded secrets are committed to version control and visible in logs and deployment artifacts. FIX: Read secrets via Deno.env.get('MY_SECRET'); store them in a .env file (gitignored) or a secrets manager and grant --allow-env=MY_SECRET.

Deno.run() is deprecated and removed in Deno 2. Use Deno.Command instead. Also verify that any user-provided values are not interpolated into the command (command injection risk).