TypeScript & Deno Security Vulnerabilities in 2026: CVE-2026-32260 Command Injection Chain, CVE-2026-41690 Prototype Pollution & Hardening GuideVulnérabilités TypeScript & Deno en 2026 : Chaîne d’Injection CVE-2026-32260, Pollution de Prototype CVE-2026-41690 & Guide de Durcissement

Deno was built on a promise: secure by default. Unlike Node.js, where any installed package can silently read your filesystem or open network connections, Deno requires explicit permission grants. It runs TypeScript natively, uses URL imports instead of a centralized registry, and ships with a built-in lockfile. In 2026, TypeScript became GitHub’s #1 programming language by monthly contributor count, with 2.63 million active contributors — a 66% year-over-year jump. Deno crossed 107,000 GitHub stars and 250,000 monthly active users, with enterprise adoption at Slack, Plaid, The Guardian, and Netlify. The security story, however, is more complicated than the marketing suggests.

Deno a été construit sur une promesse : sécurisé par défaut. Contrairement à Node.js, où n’importe quel package installé peut silencieusement lire votre système de fichiers ou ouvrir des connexions réseau, Deno exige des autorisations explicites. Il exécute TypeScript nativement, utilise des imports par URL plutôt qu’un registre centralisé, et embarque un lockfile natif. En 2026, TypeScript est devenu le langage #1 sur GitHub par nombre de contributeurs mensuels, avec 2,63 millions de contributeurs actifs — une hausse de 66% d’une année sur l’autre. Deno a dépassé 107 000 étoiles GitHub et 250 000 utilisateurs mensuels actifs. Mais l’histoire de sécurité est plus complexe que le marketing ne le laisse entendre.

Between January and May 2026, Deno disclosed four CVEs — three of them command injection vulnerabilities, one a prototype pollution flaw affecting both Deno and Node.js ecosystems. The most alarming is CVE-2026-32260 (CVSS 8.1), a bypass of a previously issued patch: Deno 2.7.0 and 2.7.1 fixed CVE-2026-27190 incorrectly, and attackers on those versions could still inject arbitrary OS commands through Deno’s node:child_process polyfill. This guide covers all four CVEs, Deno’s import maps supply chain attack surface, TypeScript type confusion vulnerabilities, and a complete hardening checklist for 2026.

Entre janvier et mai 2026, Deno a divulgué quatre CVE — dont trois vulnérabilités d’injection de commandes et une pollution de prototype affectant à la fois Deno et Node.js. La plus préoccupante est CVE-2026-32260 (CVSS 8.1), un contournement d’un correctif précédemment publié : Deno 2.7.0 et 2.7.1 avaient mal corrigé CVE-2026-27190, et les attaquants sur ces versions pouvaient toujours injecter des commandes OS arbitraires via le polyfill node:child_process. Ce guide couvre les quatre CVE, la surface d’attaque supply chain des import maps Deno, les vulnérabilités de confusion de types TypeScript, et une checklist de durcissement complète pour 2026.

TypeScript & Deno in 2026 — A Rapidly Growing Attack Surface

TypeScript & Deno en 2026 — Une Surface d’Attaque en Forte Croissance

The scale at which TypeScript and Deno are being adopted makes their security posture a matter of urgency for development teams worldwide. According to the State of JavaScript 2025 survey, 78% of professional developers use TypeScript in 2026, up from 69% in 2024. 40% of respondents now write exclusively in TypeScript, and among Fortune 500 companies with significant web development teams, TypeScript adoption exceeds 80%. TypeScript surpassed both Python and JavaScript to become GitHub’s #1 language by contributor count in August 2025, growing 66% year-over-year to 2.63 million active contributors.

L’échelle à laquelle TypeScript et Deno sont adoptés rend leur posture de sécurité urgente pour les équipes de développement mondiales. Selon l’enquête State of JavaScript 2025, 78 % des développeurs professionnels utilisent TypeScript en 2026, contre 69 % en 2024. 40 % des répondants écrivent exclusivement en TypeScript, et parmi les entreprises Fortune 500 ayant des équipes de développement web importantes, l’adoption de TypeScript dépasse 80 %. TypeScript a dépassé Python et JavaScript pour devenir le langage #1 sur GitHub par nombre de contributeurs en août 2025, avec 2,63 millions de contributeurs actifs (+66 % en un an).

Deno’s enterprise footprint has expanded significantly. Plaid migrated 100 services 5x faster using Deno’s tooling. The Guardian uses Deno to audit accessibility across 2.7 million articles. Slack saved months of engineering effort building their new platform with Deno. Netlify uses Deno Subhosting for edge functions. This enterprise adoption means that Deno CVEs carry direct business impact at scale — not just for hobbyist projects.

L’empreinte enterprise de Deno s’est considérablement élargie. Plaid a migré 100 services 5 fois plus vite grâce à l’outillage Deno. The Guardian utilise Deno pour auditer l’accessibilité de 2,7 millions d’articles. Slack a gagné des mois d’ingénierie en construisant sa nouvelle plateforme avec Deno. Netlify utilise Deno Subhosting pour ses edge functions. Cette adoption enterprise signifie que les CVE Deno ont un impact business direct à grande échelle.

CVE-2026-22864 — Windows Batch File Bypass via Case-Sensitive Extension Check (CVSS 8.1)

CVE-2026-22864 — Contournement Fichiers Batch Windows par Casse des Extensions (CVSS 8.1)

Disclosed January 15, 2026, CVE-2026-22864 is the first in a string of 2026 Deno CVEs targeting the runtime’s subprocess handling. The bug is deceptively simple: Deno implemented a security check to prevent execution of Windows batch files (.bat, .cmd) when spawning child processes, because batch files in Windows can execute arbitrary shell commands. The check, however, was case-sensitive. By specifying an extension like .BAT, .Bat, or .CMD, an attacker could bypass the protection entirely.

Divulguée le 15 janvier 2026, CVE-2026-22864 est la première d’une série de CVE Deno 2026 ciblant la gestion des sous-processus du runtime. Le bug est d’une simplicité trompeuse : Deno avait implémenté une vérification de sécurité pour empêcher l’exécution de fichiers batch Windows (.bat, .cmd) lors de la création de processus enfants, car ces fichiers peuvent exécuter des commandes shell arbitraires. La vérification était cependant sensible à la casse. En spécifiant une extension comme .BAT, .Bat ou .CMD, un attaquant pouvait contourner complètement la protection.

The fix in Deno 2.5.6 performs a case-insensitive comparison against the blocked extension list. If your Deno application on Windows spawns child processes with user-controlled filenames or accepts file paths from external inputs (API requests, CLI arguments, uploaded files), you were exposed prior to 2.5.6. Upgrade immediately and audit any code path where user-controlled strings reach Deno.Command, Deno.run, or child_process.spawnSync.

Le correctif dans Deno 2.5.6 effectue une comparaison insensible à la casse de la liste des extensions bloquées. Si votre application Deno sous Windows crée des processus enfants avec des noms de fichiers contrôlés par l’utilisateur ou accepte des chemins de fichiers depuis des entrées externes (requêtes API, arguments CLI, fichiers uploadés), vous étiez exposé avant la version 2.5.6. Mettez à jour immédiatement et auditez tout chemin de code où des chaînes contrôlées par l’utilisateur atteignent Deno.Command, Deno.run ou child_process.spawnSync.

CVE-2026-27190 & CVE-2026-32260 — A Command Injection Chain That Bypassed Its Own Fix

CVE-2026-27190 & CVE-2026-32260 — Une Chaîne d’Injection de Commandes Qui a Contourné Son Propre Correctif

These two CVEs tell the story of an incomplete fix — a pattern that has become increasingly common in security research. CVE-2026-27190 was discovered in Deno’s node:child_process compatibility layer: the implementation that allows Deno to run code written for Node.js. When running spawnSync or spawn with shell: true, Deno passes arguments through a custom sanitizer called transformDenoShellCommand. The sanitizer maintained an incomplete blocklist of shell metacharacters, missing several characters that allow command injection in POSIX shells. An attacker who controls arguments passed to spawnSync or spawn with shell: true could inject and execute arbitrary OS commands, bypassing Deno’s permission system entirely.

Ces deux CVE racontent l’histoire d’un correctif incomplet — un schéma de plus en plus courant en recherche de sécurité. CVE-2026-27190 a été découverte dans la couche de compatibilité node:child_process de Deno : l’implémentation qui permet à Deno d’exécuter du code écrit pour Node.js. Lors de l’utilisation de spawnSync ou spawn avec shell: true, Deno fait passer les arguments par un sanitizer personnalisé appelé transformDenoShellCommand. Ce sanitizer maintenait une liste de blocage incomplète des métacaractères shell, manquant plusieurs caractères permettant l’injection de commandes dans les shells POSIX. Un attaquant contrôlant les arguments passés à spawnSync ou spawn avec shell: true pouvait injecter et exécuter des commandes OS arbitraires, contournant entièrement le système de permissions Deno.

The Deno team issued a patch in version 2.6.8 for CVE-2026-27190 — but the fix introduced CVE-2026-32260 (CVSS 8.1, disclosed March 12, 2026). The two-stage argument sanitization in transformDenoShellCommand had a priority bug: when an argument contains a $VAR pattern (dollar sign followed by a variable name), the sanitizer wraps the argument in double quotes instead of single quotes. In POSIX sh, double quotes do not suppress backtick command substitution (`command`) or $(command) substitution. This allowed attackers on Deno 2.7.0–2.7.1 to bypass the CVE-2026-27190 fix by constructing arguments containing backtick-wrapped shell commands alongside a $VAR pattern.

L’équipe Deno a publié un correctif dans la version 2.6.8 pour CVE-2026-27190 — mais ce correctif a introduit CVE-2026-32260 (CVSS 8.1, divulguée le 12 mars 2026). La sanitisation d’arguments en deux étapes dans transformDenoShellCommand contenait un bug de priorité : lorsqu’un argument contient un motif $VAR (signe dollar suivi d’un nom de variable), le sanitizer entoure l’argument de guillemets doubles au lieu de guillemets simples. En sh POSIX, les guillemets doubles ne supprime pas la substitution de commandes par guillemets obliques (`commande`) ni la substitution $(commande). Cela permettait aux attaquants sur Deno 2.7.0–2.7.1 de contourner le correctif CVE-2026-27190 en construisant des arguments contenant des commandes shell entre guillemets obliques associées à un motif $VAR.

# Example of the bypass in Deno 2.7.0-2.7.1 (conceptual — do NOT use in production)
# When an argument contains $VAR, it gets wrapped in double quotes:
# spawnSync("sh", ["-c", "echo $HOME"], { shell: true })
# Sanitizer output: sh -c "echo $HOME"
# But if argument is: `whoami` $HOME
# Sanitizer output: "`whoami` $HOME" — backtick executes!
# Fix in 2.7.2: use single quotes, which suppress ALL shell expansions

The fix in Deno 2.7.2 switches to wrapping arguments in single quotes, which in POSIX sh suppress all forms of expansion — variable substitution ($VAR), backtick substitution (`cmd`), and $(cmd) substitution. If you are running Deno 2.7.0 or 2.7.1, upgrade to 2.7.2 immediately. Any application that accepts user input and passes it to child_process.spawn, child_process.spawnSync, or child_process.exec with shell: true while running Deno 2.7.0–2.7.1 may be exploitable.

Le correctif dans Deno 2.7.2 passe à l’utilisation de guillemets simples, qui en sh POSIX suppriment toutes les formes d’expansion — substitution de variables ($VAR), substitution par guillemets obliques (`cmd`) et substitution $(cmd). Si vous utilisez Deno 2.7.0 ou 2.7.1, mettez à jour immédiatement vers 2.7.2. Toute application acceptant des entrées utilisateur et les transmettant à child_process.spawn, child_process.spawnSync ou child_process.exec avec shell: true sous Deno 2.7.0–2.7.1 peut être exploitable.

CVE-2026-41690 — Prototype Pollution in 18next-http-middleware (CVSS 8.6)

CVE-2026-41690 — Pollution de Prototype dans 18next-http-middleware (CVSS 8.6)

CVE-2026-41690 scores CVSS 8.6 (High) and affects a dependency widely used in both Node.js and Deno applications: i18next-http-middleware, the server-side middleware for the popular i18next internationalization library. The vulnerability allows unauthenticated HTTP clients to pollute Object.prototype by sending specially crafted HTTP headers. This type of attack — prototype pollution — is particularly insidious because it can silently corrupt the behavior of any JavaScript code that relies on inherited object properties, potentially bypassing authorization checks, corrupting data validation logic, or enabling Remote Code Execution.

CVE-2026-41690 obtient un score CVSS 8.6 (High) et affecte une dépendance largement utilisée dans les applications Node.js et Deno : i18next-http-middleware, le middleware serveur de la bibliothèque d’internationalisation i18next. La vulnérabilité permet à des clients HTTP non authentifiés de polluer Object.prototype en envoyant des en-têtes HTTP spécialement crés. Ce type d’attaque — la pollution de prototype — est particulièrement insidieux car il peut corrompre silencieusement le comportement de tout code JavaScript reposant sur des propriétés d’objet héritées, contournant potentiellement les vérifications d’autorisation ou activant une exécution de code à distance.

The attack works by sending malformed language detection headers that the middleware processes without proper sanitization. In JavaScript, if you can set Object.prototype.isAdmin = true via prototype pollution, then any object in the application that checks obj.isAdmin without explicitly verifying the property source will evaluate it as truthy — a classic authorization bypass. Applications using i18next for server-side language detection (common in Express, Koa, Fastify, and Deno HTTP servers) should audit their i18next-http-middleware version and patch to the latest release immediately.

L’attaque fonctionne en envoyant des en-têtes de détection de langue mal formés que le middleware traite sans désinfection adéquate. En JavaScript, si un attaquant peut définir Object.prototype.isAdmin = true via la pollution de prototype, alors tout objet dans l’application qui vérifie obj.isAdmin sans vérifier explicitement la source de la propriété l’évaluera comme vrai — un contournement d’autorisation classique. Les applications utilisant i18next pour la détection de langue côté serveur (courant dans Express, Koa, Fastify et les serveurs HTTP Deno) doivent auditer leur version d’i18next-http-middleware et appliquer le correctif immédiatement.

# Check your installed version
npm list i18next-http-middleware
# or in Deno with npm: imports
deno info npm:i18next-http-middleware

# Also check for prototype pollution in your codebase:
grep -r "Object.prototype" src/ --include="*.ts"
grep -r "\[.*\]" src/ --include="*.ts" | grep -v "// "  # bracket notation with variable keys

Deno’s Import Maps & Supply Chain Attack Surface

Import Maps Deno & Surface d’Attaque Supply Chain

Deno’s URL-based import system was designed to eliminate npm’s centralized registry as a single point of failure. Instead of import express from "express", you write import express from "https://deno.land/x/express/mod.ts". This decentralization sounds secure, but research presented at NDSS 2025 (published February 2026) from CISPA Helmholtz Center for Information Security identified critical supply chain risks in Deno’s import system.

Le système d’import basé sur des URL de Deno a été conçu pour éliminer le registre npm centralisé comme point de défaillance unique. Au lieu de import express from "express", on écrit import express from "https://deno.land/x/express/mod.ts". Cette décentralisation paraît sécurisée, mais des recherches présentées à l’NDSS 2025 (publiées en février 2026) par le CISPA Helmholtz Center for Information Security ont identifié des risques critiques de supply chain dans le système d’import Deno.

The key finding: URL imports in Deno are exempted from permission checks. The permission system (--allow-net, --allow-read, etc.) governs what your code can do once it runs, but it does not prevent Deno from fetching and executing arbitrary code from a remote URL during the import phase. If an attacker compromises a remote module you depend on — via a hijacked CDN, a domain that expired and was re-registered, or a man-in-the-middle attack — Deno will fetch and execute that code regardless of your permission flags. The research led to two security advisories and a redesign of Deno’s import integrity mechanism in Deno 2.x.

La découverte clé : les imports par URL dans Deno sont exemptés des vérifications de permissions. Le système de permissions (--allow-net, --allow-read, etc.) régit ce que votre code peut faire une fois qu’il s’exécute, mais il n’empêche pas Deno de récupérer et d’exécuter du code arbitraire depuis une URL distante pendant la phase d’import. Si un attaquant compromet un module distant dont vous dépendez — via un CDN piraté, un domaine expiré réenregistré, ou une attaque man-in-the-middle — Deno récupérera et exécutera ce code sans tenir compte de vos indicateurs de permissions. La recherche a conduit à deux advisories de sécurité et une refonte du mécanisme d’intégrité des imports dans Deno 2.x.

The solution is deno.lock — Deno’s lockfile. Unlike npm’s package-lock.json, which locks package versions, deno.lock stores cryptographic hashes of every remote module’s content. If a remote module changes after you first import it, Deno will detect the mismatch and refuse to run. This is a powerful security primitive — but only if you use it correctly:

La solution est deno.lock — le lockfile de Deno. Contrairement au package-lock.json de npm, qui verrouille les versions des packages, deno.lock stocke des hachages cryptographiques du contenu de chaque module distant. Si un module distant change après votre premier import, Deno détectera la discordance et refusera d’exécuter. C’est une primitive de sécurité puissante — mais seulement si vous l’utilisez correctement :

# Generate/update the lockfile (run locally when updating deps)
deno cache --lock=deno.lock --lock-write deps.ts

# In CI/production: use --frozen-lockfile to prevent unexpected dep changes
deno run --frozen-lockfile --allow-net main.ts

# Or in deno.json (recommended for projects):
{
  "lock": true,
  "nodeModulesDir": "auto",
  "tasks": {
    "start": "deno run --frozen-lockfile --allow-net main.ts"
  }
}

# CRITICAL: commit deno.lock to version control
# A missing deno.lock means every CI run can silently fetch changed modules

TypeScript Type Confusion — When Types Give a False Sense of Security

Confusion de Types TypeScript — Quand les Types Donnent un Faux Sentiment de Sécurité

TypeScript’s type system is excellent at catching bugs at compile time, but it provides no runtime security guarantees. Types are erased during compilation — at runtime, your TypeScript application is just JavaScript. This distinction matters because data flowing into your application from HTTP requests, databases, or file reads is untyped at the boundary. A common misconception: “I declared the parameter as string, so it can’t be a dangerous value.” Wrong.

Le système de types TypeScript est excellent pour détecter les bugs à la compilation, mais il ne fournit aucune garantie de sécurité à l’exécution. Les types sont effacés lors de la compilation — à l’exécution, votre application TypeScript n’est que du JavaScript. Cette distinction importe car les données entrant dans votre application via des requêtes HTTP, des bases de données ou des lectures de fichiers ne sont pas typées à la frontière. Une idée reçue courante : “J’ai déclaré le paramètre comme string, donc il ne peut pas être une valeur dangereuse.” Faux.

CVE-2026-25049 illustrates this perfectly: a type confusion vulnerability in the n8n workflow automation platform (built with TypeScript) allowed attackers to achieve Remote Code Execution by exploiting a disconnect between TypeScript’s compile-time type annotations and the actual runtime data types. When n8n passed user-controlled data through what TypeScript believed was a safely-typed pipeline, the underlying JavaScript runtime received raw attacker input that the workflow engine executed. The TypeScript type system flagged nothing — because the types were technically correct, but the runtime validation was absent.

CVE-2026-25049 illustre parfaitement ceci : une vulnérabilité de confusion de types dans la plateforme d’automatisation de workflow n8n (construite avec TypeScript) a permis à des attaquants d’obtenir une exécution de code à distance en exploitant un décalage entre les annotations de types TypeScript à la compilation et les types de données réels à l’exécution. Lorsque n8n passait des données contrôlées par l’utilisateur dans ce que TypeScript considérait comme un pipeline sûrement typé, le runtime JavaScript sous-jacent recevait des entrées brutes de l’attaquant que le moteur de workflow exécutait. Le système de types TypeScript n’a rien signalé — car les types étaient techniquement corrects, mais la validation à l’exécution était absente.

// DANGEROUS: TypeScript type annotation does not validate at runtime
interface UserInput {
  username: string;
  age: number;
}

async function processUser(input: UserInput) {
  // TypeScript thinks this is safe — but at runtime, input comes from req.body
  // An attacker can send: { username: { __proto__: { isAdmin: true } }, age: "DROP TABLE users--" }
  const query = `SELECT * FROM users WHERE name = '${input.username}'`;
  // SQL injection! TypeScript saw a "string", not the attack payload
}

// SAFE: runtime validation with a parsing library
import { z } from "zod"; // or class-validator, arktype, etc.

const UserSchema = z.object({
  username: z.string().max(50).regex(/^[a-zA-Z0-9_]+$/),
  age: z.number().int().min(0).max(150),
});

async function processUserSafe(rawInput: unknown) {
  const input = UserSchema.parse(rawInput); // throws if invalid at runtime
  // Now safe to use input.username
}

Additionally, TypeScript 7.0 — targeting mid-2026 with a Go-based compiler rewrite — will introduce new potential attack surfaces. The Go compiler port dramatically changes the runtime characteristics of the TypeScript compiler itself. Security teams should plan to audit any build pipeline tooling that invokes tsc directly as soon as TypeScript 7 is released, especially in CI/CD environments where the compiler processes untrusted input (e.g., third-party TypeScript code in monorepos or plugin systems).

De plus, TypeScript 7.0 — ciblé pour mi-2026 avec une réécriture du compilateur en Go — va introduire de nouvelles surfaces d’attaque potentielles. Le portage du compilateur en Go change radicalement les caractéristiques d’exécution du compilateur TypeScript lui-même. Les équipes de sécurité devraient planifier d’auditer tout outil de pipeline de build invoquant tsc directement dès la sortie de TypeScript 7, notamment dans les environnements CI/CD où le compilateur traite des entrées non fiables (code TypeScript tiers dans des monorepos ou des systèmes de plugins).

Deno & TypeScript Security Hardening Guide 2026

Guide de Durcissement Sécurité Deno & TypeScript 2026

1 — Keep Deno Updated and Pin to a Specific Version in CI

1 — Maintenir Deno à Jour et Fixer une Version Spécifique en CI

The CVE-2026-32260 chain shows how critical it is to track Deno patch releases. Deno 2.7.0 and 2.7.1 contained a regression that reintroduced the CVE-2026-27190 vulnerability. In CI/CD, never run deno upgrade without testing — pin to a known-good version in your CI config:

La chaîne CVE-2026-32260 montre l’importance critique de suivre les releases de correctifs Deno. Deno 2.7.0 et 2.7.1 contenaient une régression qui réintroduisait la vulnérabilité CVE-2026-27190. En CI/CD, ne jamais exécuter deno upgrade sans tests — fixez une version connue dans votre config CI :

# GitHub Actions: pin Deno version
- uses: denoland/setup-deno@v2
  with:
    deno-version: "2.7.2"  # NOT "v1.x" or "latest"

# Or via .tool-versions (asdf/mise)
deno 2.7.2

# Check your current version
deno --version

2 — Never Use shell: true with Untrusted Arguments

2 — Ne Jamais Utiliser shell: true avec des Arguments Non Fiables

CVE-2026-27190 and CVE-2026-32260 both require shell: true in the spawn call. The most effective mitigation is to never pass user-controlled values to shell commands. If you must spawn subprocesses with user input, pass arguments as an array (without shell: true) so the OS handles escaping at the system call level, bypassing shell interpretation entirely:

CVE-2026-27190 et CVE-2026-32260 nécessitent toutes deux shell: true dans l’appel spawn. L’atténuation la plus efficace est de ne jamais passer de valeurs contrôlées par l’utilisateur aux commandes shell. Si vous devez créer des sous-processus avec des entrées utilisateur, passez les arguments sous forme de tableau (sans shell: true) pour que l’OS gère l’échappement au niveau de l’appel système, contournant entièrement l’interprétation du shell :

// DANGEROUS: shell: true with user input
import { spawnSync } from "node:child_process";
const userInput = req.body.filename; // attacker-controlled!
spawnSync("convert", [userInput, "output.png"], { shell: true }); // VULN

// SAFE: array args, no shell: true
spawnSync("convert", [userInput, "output.png"]); // OS escaping, no shell

// ALSO SAFE: use Deno's native subprocess API with array args
const cmd = new Deno.Command("convert", {
  args: [userInput, "output.png"], // shell never involved
});
await cmd.output();

3 — Commit and Freeze Your deno.lock

3 — Committer et Géler Votre deno.lock

A missing or uncommitted deno.lock means your application re-fetches remote modules on every run, silently accepting any changes. Enable lockfile enforcement in your project’s deno.json and use --frozen-lockfile in production and CI:

Un deno.lock manquant ou non commité signifie que votre application re-récupère les modules distants à chaque exécution, acceptant silencieusement toute modification. Activez l’application du lockfile dans le deno.json de votre projet et utilisez --frozen-lockfile

// deno.json
{
  "lock": true,
  "imports": {
    "zod": "npm:zod@3.23.8",
    "hono": "jsr:@hono/hono@4.7.7"
  },
  "tasks": {
    "start": "deno run --frozen-lockfile --allow-net --allow-read main.ts",
    "test": "deno test --frozen-lockfile"
  }
}

# Also: use JSR (jsr.io) over deno.land/x — JSR uses signed provenance attestations

// Option 1: Zod (most popular, npm-compatible)
import { z } from "npm:zod@3.23.8";
const Body = z.object({ name: z.string().max(100), age: z.number().int().positive() });
const data = Body.parse(await req.json()); // throws ZodError if invalid

// Option 2: Valibot (smaller bundle, Deno-friendly)
import * as v from "npm:valibot@1.0.0";
const Body = v.object({ name: v.pipe(v.string(), v.maxLength(100)) });

// Option 3: ArkType (TypeScript-native, zero runtime overhead for simple schemas)
import { type } from "npm:arktype@2.1.0";
const Body = type({ name: "string <= 100", age: "integer > 0" });

# BAD: grants everything (equivalent to no security model)
deno run --allow-all main.ts

# GOOD: minimal permissions
deno run \
  --allow-net=api.example.com:443,db.internal:5432 \
  --allow-read=/app/static,/app/config/app.json \
  --allow-env=DATABASE_URL,JWT_SECRET \
  --frozen-lockfile \
  main.ts

# GOOD: permissions in deno.json for reproducible runs
{
  "tasks": {
    "start": "deno run --allow-net=api.example.com --allow-read=/app --frozen-lockfile main.ts"
  }
}