# Node.js 24 nel 2026: URLPattern, Permission Model e Domande per Colloqui Tecnici > Node.js 24 LTS introduce un Permission Model stabile, URLPattern globale, gestione esplicita delle risorse con using/await using e V8 13.6. Un approfondimento sulle funzionalità rilevanti per la produzione e i colloqui tecnici. - Published: 2026-05-31 - Updated: 2026-05-31 - Author: SharpSkill - Tags: node.js, node.js 24, urlpattern, permissions, interview, v8, javascript - Reading time: 10 min --- Node.js 24, nome in codice Krypton, ha raggiunto lo stato LTS nell'ottobre 2025 e rimane la versione consigliata per la produzione nel 2026. Questa release stabilizza il Permission Model, promuove URLPattern ad API globale, introduce la gestione esplicita delle risorse tramite V8 13.6 e aggiorna npm alla versione 11. Queste modifiche influenzano direttamente il modo in cui le applicazioni backend gestiscono sicurezza, routing e ciclo di vita delle risorse. > **Node.js 24 LTS in sintesi** > > V8 13.6 con `using`/`await using`, flag stabile `--permission` in sostituzione di `--experimental-permission`, `URLPattern` globale per routing senza framework, npm 11 e Undici 7 come client HTTP predefinito. L'ultima patch è la 24.16.0 (maggio 2026). ## Il Permission Model: Da Sperimentale a Pronto per la Produzione Node.js 20 aveva introdotto il Permission Model dietro il flag `--experimental-permission`. Node.js 24 rimuove il prefisso `experimental`. Il flag è ora semplicemente `--permission`, e il runtime limita l'accesso al filesystem, alla rete, ai processi figlio, agli addon nativi e alle variabili d'ambiente a meno che non sia esplicitamente consentito. Questo aspetto è cruciale per la sicurezza della supply chain. Una dipendenza compromessa non può esfiltrare dati attraverso la rete o leggere file arbitrari se il processo gira sotto `--permission` con permessi strettamente definiti. ```bash # launch-secure.sh # Run an API server with minimal permissions node --permission \ --allow-fs-read=/app/src,/app/config \ --allow-fs-write=/app/uploads \ --allow-net=0.0.0.0:3000 \ server.js ``` Il processo sopra indicato può solo leggere le directory del codice sorgente e della configurazione, scrivere nella cartella uploads e ascoltare sulla porta 3000. Qualsiasi tentativo di avviare un processo figlio, caricare un addon nativo o accedere a variabili d'ambiente al di fuori dello scope consentito genera un errore `ERR_ACCESS_DENIED`. ### Verifiche dei Permessi a Runtime con process.permission Il metodo `process.permission.has()` consente l'introspezione a runtime. Il codice dell'applicazione può verificare le proprie capacità prima di tentare operazioni con restrizioni. ```javascript // permission-check.js // Verify permissions before performing restricted operations function ensureWriteAccess(directory) { if (!process.permission.has('fs.write', directory)) { throw new Error(`No write permission for ${directory}`); } } function canSpawnProcesses() { return process.permission.has('child'); } // Gracefully degrade when network access is restricted function fetchWithFallback(url, cachedData) { if (!process.permission.has('net')) { console.warn('Network access denied, using cached data'); return cachedData; } return fetch(url); } ``` Questo pattern è particolarmente utile per le librerie che devono funzionare sia in ambienti sandboxed che in ambienti senza restrizioni. La patch di sicurezza di marzo 2026 per Node.js 24.14.1 ha inoltre corretto un bypass in `FileHandle.chmod()` e `FileHandle.chown()` che saltava i controlli dei permessi, sottolineando l'importanza di mantenere aggiornato il runtime. ## URLPattern Globale: Route Matching Nativo Senza Dipendenze Node.js 24 espone [URLPattern](https://developer.mozilla.org/en-US/docs/Web/API/URLPattern) nello scope globale. Questo standard WHATWG fornisce pattern matching simile alle regex progettato specificamente per gli URL, con gruppi nominati, segmenti opzionali e vincoli di validazione. Non serve alcun `import` o `require`. L'API funziona in modo identico nei browser, in Cloudflare Workers e in Deno, rendendola una primitiva di routing genuinamente portabile. ```javascript // router.js // Framework-free HTTP router using global URLPattern const routes = [ { pattern: new URLPattern({ pathname: '/api/users/:userId' }), handler: handleGetUser }, { pattern: new URLPattern({ pathname: '/api/users/:userId/posts/:postId' }), handler: handleGetPost }, { // Optional segment: matches /api/products and /api/products/:category pattern: new URLPattern({ pathname: '/api/products{/:category}?' }), handler: handleProducts } ]; function matchRoute(url) { for (const route of routes) { const result = route.pattern.exec(url); if (result) { return { handler: route.handler, params: result.pathname.groups }; } } return null; } // Usage with Node.js HTTP server import { createServer } from 'node:http'; const server = createServer((req, res) => { const url = new URL(req.url, `http://${req.headers.host}`); const match = matchRoute(url.href); if (match) { match.handler(req, res, match.params); } else { res.writeHead(404).end('Not Found'); } }); server.listen(3000); ``` ### Validazione dei Pattern e Matching Avanzato URLPattern supporta vincoli regex inline sui gruppi nominati, matching del protocollo e filtraggio per hostname. Il metodo `test()` restituisce un booleano per controlli rapidi senza allocare un oggetto risultato del match. ```javascript // url-validation.js // Validate URL segments with inline regex constraints const numericUser = new URLPattern({ pathname: '/users/:id([0-9]+)' }); numericUser.test('https://app.com/users/42'); // true numericUser.test('https://app.com/users/alice'); // false // Match by protocol and hostname const secureApi = new URLPattern({ protocol: 'https', hostname: 'api.example.com', pathname: '/v2/*' }); // Service worker-style routing for static assets vs API calls const staticAssets = new URLPattern({ pathname: '/static/*' }); const apiCalls = new URLPattern({ pathname: '/api/*' }); ``` Dal punto di vista delle prestazioni, URLPattern non è progettato per competere con router ottimizzati come [find-my-way](https://github.com/delvedor/find-my-way) in termini di throughput puro. Il suo valore risiede nella portabilità tra runtime diversi e in un'API standardizzata che elimina i bug di parsing dei percorsi. ## Gestione Esplicita delle Risorse: using e await using V8 13.6 in Node.js 24 implementa la proposta TC39 [Explicit Resource Management](https://github.com/tc39/proposal-explicit-resource-management). Le dichiarazioni `using` e `await using` sostituiscono i blocchi `try/finally` per la pulizia deterministica di file handle, connessioni al database, lock e qualsiasi oggetto che implementi `Symbol.dispose` o `Symbol.asyncDispose`. A partire da Node.js 24.2.0, `Symbol.dispose` e `Symbol.asyncDispose` non sono più sperimentali. ```javascript // resource-management.js // Automatic cleanup with using and await using import { open } from 'node:fs/promises'; async function processCSV(path) { // File handle is automatically closed when scope exits await using file = await open(path, 'r'); const content = await file.readFile({ encoding: 'utf8' }); return content.split('\n').length; // file[Symbol.asyncDispose]() called here automatically } // Custom disposable resource function createDatabasePool(connectionString) { const pool = new Pool(connectionString); return { pool, query: (sql, params) => pool.query(sql, params), [Symbol.asyncDispose]: async () => { await pool.end(); console.log('Pool connections released'); } }; } async function runMigrations() { await using db = createDatabasePool(process.env.DB_URL); await db.query('CREATE TABLE IF NOT EXISTS migrations ...'); // Pool automatically closed, no try/finally needed } ``` ### DisposableStack per Risorse Multiple `DisposableStack` e `AsyncDisposableStack` aggregano più risorse disposable. Quando lo stack viene rilasciato, le risorse vengono liberate in ordine inverso, gestendo correttamente le catene di dipendenze. ```javascript // disposable-stack.js // Manage multiple resources with AsyncDisposableStack async function processTransaction() { await using stack = new AsyncDisposableStack(); const connection = stack.use(await getConnection()); const transaction = stack.use(await connection.beginTransaction()); const tempFile = stack.use(await createTempFile()); await transaction.execute('INSERT INTO orders ...'); await tempFile.write('backup data'); // On scope exit: tempFile closed, transaction committed/rolled back, // connection returned to pool (reverse order) } ``` Questo pattern elimina un'intera classe di bug legati ai resource leak. Il tipo `SuppressedError` gestisce il caso limite in cui il rilascio stesso genera un errore, preservando sia l'errore originale che quello di rilascio. ## V8 13.6: Funzionalità del Motore JavaScript da Conoscere Oltre alla gestione esplicita delle risorse, V8 13.6 introduce diverse funzionalità che compaiono nei [colloqui tecnici su Node.js](/technologies/node-nestjs). **RegExp.escape** sanitizza le stringhe per l'incorporamento sicuro nelle espressioni regolari: ```javascript // regexp-escape.js // Safely embed user input in regular expressions const userInput = 'price: $9.99 (USD)'; const escaped = RegExp.escape(userInput); // escaped: 'price\:\ \$9\.99\ \(USD\)' const pattern = new RegExp(escaped); ``` **Float16Array** aggiunge un typed array a virgola mobile a 16 bit, dimezzando l'utilizzo di memoria rispetto a `Float32Array` per carichi di lavoro come l'inferenza ML o la preparazione dei buffer WebGL: ```javascript // float16.js // Half-precision floating point for memory-sensitive workloads const weights = new Float16Array([0.5, -1.25, 3.14]); console.log(weights.byteLength); // 6 bytes instead of 12 with Float32Array ``` **Error.isError** fornisce un controllo di tipo affidabile che funziona attraverso i realm (iframe, contesti vm, worker thread): ```javascript // error-check.js // Cross-realm error detection const err = new TypeError('invalid input'); Error.isError(err); // true Error.isError({ message: 'fake' }); // false ``` ## Miglioramento delle Prestazioni di AsyncLocalStorage Node.js 24 passa all'implementazione `AsyncContextFrame` come predefinita per `AsyncLocalStorage`. Le versioni precedenti utilizzavano un approccio basato su hook che aggiungeva overhead a ogni operazione asincrona. La nuova implementazione si integra direttamente con la coda dei microtask di V8, riducendo il costo prestazionale della propagazione del contesto in applicazioni ad alta concorrenza. Questa modifica è trasparente per il codice esistente. Librerie come [OpenTelemetry](https://opentelemetry.io/) e framework di logging che si affidano a `AsyncLocalStorage` per il contesto a livello di richiesta vedono miglioramenti misurabili del throughput senza modifiche al codice. ```javascript // async-context.js // Request-scoped context with improved AsyncLocalStorage import { AsyncLocalStorage } from 'node:async_hooks'; const requestContext = new AsyncLocalStorage(); function handleRequest(req, res) { const context = { requestId: crypto.randomUUID(), startTime: performance.now() }; requestContext.run(context, async () => { // Context automatically propagated through all async operations const data = await fetchUserData(req.userId); const elapsed = performance.now() - requestContext.getStore().startTime; logger.info(`Request ${requestContext.getStore().requestId} completed in ${elapsed}ms`); res.json(data); }); } ``` ## Domande per Colloqui Tecnici: Edizione Node.js 24 Queste domande riflettono le funzionalità e i pattern su cui i recruiter si concentrano nel 2026. Ogni risposta dimostra una comprensione a livello produttivo piuttosto che una conoscenza superficiale. **D1: In che modo il Permission Model di Node.js differisce dal sandboxing a livello di sistema operativo?** Il Permission Model opera a livello di runtime Node.js, non a livello di kernel del sistema operativo. Limita l'accesso alle API built-in di Node.js (`fs`, `net`, `child_process`) in base ai flag CLI. Il sandboxing a livello OS (container, seccomp, AppArmor) opera al di sotto del runtime e limita le syscall. Il Permission Model integra il sandboxing OS fornendo granularità a livello applicativo. Una limitazione fondamentale: non si applica agli addon nativi che bypassano le API di Node.js, e i file descriptor esistenti aperti prima del controllo dei permessi possono ancora essere utilizzati. **D2: Quando URLPattern sarebbe una scelta inadeguata rispetto a un router dedicato?** URLPattern non supporta middleware, routing basato sul metodo HTTP (GET vs POST) e garanzie sull'ordinamento delle route. Esegue matching lineare durante l'iterazione su un array di pattern, mentre router come [find-my-way](https://github.com/delvedor/find-my-way) utilizzano alberi radix per lookup O(log n). URLPattern è appropriato per la logica di validazione condivisa client-server, i fetch handler dei service worker e i prototipi. Le API HTTP di produzione con centinaia di route traggono vantaggio da un router dedicato. **D3: Qual è la differenza tra `using` e `await using`? Quando è appropriato ciascuno?** `using` chiama `[Symbol.dispose]()` in modo sincrono quando il blocco termina. Funziona per risorse come mutex, file descriptor gestiti da addon C++ sincroni o cache in memoria. `await using` chiama `[Symbol.asyncDispose]()` e ne attende il risultato, rendendolo necessario per connessioni al database, sessioni HTTP o qualsiasi pulizia che coinvolga I/O asincrono. L'uso di `using` sincrono per una risorsa asincrona salta silenziosamente la pulizia. **D4: Come migliora `AsyncContextFrame` le prestazioni di `AsyncLocalStorage`?** Le implementazioni precedenti utilizzavano async hook (`init`, `before`, `after`, `destroy`) per propagare il contesto, aggiungendo overhead a ogni risoluzione di `Promise` e callback dei timer. `AsyncContextFrame` memorizza il contesto direttamente nella catena interna delle Promise di V8, eliminando l'overhead degli hook. Il miglioramento è più significativo nei carichi di lavoro con elevato churn di `Promise`, come server HTTP che gestiscono migliaia di richieste concorrenti con tracing per-request. **D5: Quali limitazioni di sicurezza esistono nel Permission Model?** Cinque limitazioni critiche: (1) I symlink possono attraversare percorsi al di fuori di quelli consentiti. (2) Gli addon nativi bypassano completamente i controlli dei permessi. (3) I file descriptor ereditati da un processo padre o aperti prima dell'inizializzazione di `--permission` non sono soggetti a restrizioni. (4) I flag `--env-file` e `--openssl-config` leggono i file prima che il Permission Model venga inizializzato. (5) I permessi dei worker thread sono indipendenti e devono essere configurati separatamente. Il fix CVE di marzo 2026 per `FileHandle.chmod()`/`FileHandle.chown()` ha dimostrato che le nuove API devono essere continuamente verificate per l'applicazione dei permessi. ## Conclusione - **Percorso di aggiornamento**: Node.js 24 LTS (Krypton) è la versione di produzione consigliata fino ad aprile 2028. Il flag `--permission` non richiede modifiche al codice, solo configurazione del deployment - **URLPattern** elimina le dipendenze di routing leggere per il codice cross-runtime. I router dedicati restano la scelta migliore per API HTTP ad alto throughput con catene middleware complesse - **`using`/`await using`** sostituiscono `try/finally` per la gestione del ciclo di vita delle risorse. Un buon punto di partenza è aggiungere `[Symbol.asyncDispose]` ai wrapper dei pool di database e alle utility per i file handle - I miglioramenti delle prestazioni di **AsyncLocalStorage** sono automatici. La verifica avviene tramite benchmarking del logging e del tracing a livello di richiesta sotto carico - La **preparazione ai colloqui** dovrebbe coprire le limitazioni del Permission Model (symlink, addon nativi, file descriptor ereditati), i compromessi di URLPattern rispetto ai router con alberi radix e la distinzione tra disposal sincrono e asincrono - Implementare risorse disposable personalizzate e controlli dei permessi a runtime dimostra familiarità pratica con le funzionalità di Node.js 24 durante le [sessioni di colloquio backend](/technologies/node-nestjs/interview-questions/authentication-jwt) --- Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack. HTML version of this page: https://sharpskill.dev/it/blog/node-nestjs/nodejs-24-urlpattern-permissions-interview-questions