I motivi per proteggere il codice sono numerosi: impedire che il proprio lavoro venga semplicemente copiato e incollato (aspetto particolarmente importante per i progetti lato client come i giochi HTML5), rimuovere commenti e spazi per rendere il codice più veloce da caricare e più difficile da comprendere, e proteggere un lavoro non ancora pagato, così da poterlo mostrare ai clienti senza consegnare il codice sorgente.

L'offuscamento VM (Virtual Machine) trasforma il codice JavaScript in bytecode personalizzato eseguito da un interprete incorporato. A differenza dell'offuscamento standard, che produce comunque JavaScript leggibile, l'offuscamento VM nasconde completamente la struttura del codice originale. Gli strumenti di analisi statica non possono comprenderne la logica senza prima sottoporre a reverse engineering l'intera macchina virtuale. Maggiori informazioni nella guida all'offuscamento VM.

Sì. È disponibile un'opzione per applicare selettivamente l'offuscamento VM a funzioni o metodi specifici. È sufficiente annotare la funzione desiderata con un commento speciale (/* javascript-obfuscator:vm */) e solo quella funzione verrà elaborata dall'offuscatore VM. Questa soluzione è ideale per proteggere unicamente gli algoritmi più sensibili, lasciando il resto del codice con offuscamento standard oppure invariato, riducendo al minimo l'impatto sulle prestazioni.

No. Chiavi API, segreti e credenziali non devono MAI essere memorizzati nel codice frontend. Anche con il massimo livello di offuscamento, qualsiasi dato presente nel JavaScript frontend può essere estratto da un attaccante determinato. L'offuscamento rende il reverse engineering più difficile, ma non è crittografia e non deve essere considerato un mezzo per mettere al sicuro i segreti. È preferibile memorizzare i segreti sul proprio server backend, utilizzare variabili di ambiente lato server, instradare le chiamate API attraverso il backend per nascondere le chiavi oppure utilizzare token a breve durata emessi dal proprio server.

Nessun offuscamento è infallibile al 100%: il JavaScript viene comunque eseguito in un ambiente controllato dall'attaccante, browser o Node.js, e in quel contesto l'ispezione della memoria a runtime è sempre possibile. Nessun offuscamento JavaScript può impedirla del tutto; ciò che può fare è aumentarne il costo. Al momento non esistono servizi online di deoffuscamento automatico per il codice offuscato con VM: ogni offuscamento compila il codice in bytecode personalizzato con una macchina virtuale unica, il che rende impossibile realizzare strumenti universali. L'offuscamento standard è molto più semplice da superare: spesso può essere parzialmente invertito con strumenti automatici e beautifier. L'offuscamento VM richiede invece di sottoporre a reverse engineering l'intera macchina virtuale, decrittare e decodificare il suo bytecode, comprenderne il set di istruzioni e tracciarne l'esecuzione: un processo che può richiedere settimane di lavoro dedicato. Senza VM Self Defending, agenti IA potenti (ad esempio Claude Opus 4.7) possono tracciare il bytecode e ricostruire approssimativamente il codice originale nel caso di basi di codice ridotte. Con VM Self Defending abilitato, difese anti-LLM stratificate — anti-hooking, verifica dell'integrità cross-realm e controlli di nativity del bytecode — ostacolano le tecniche dinamiche con cui un agente cerca di interpretare il bytecode: strumentazione, hooking ed esecuzione in sandbox. La lettura statica del file resta possibile, ma espone soltanto bytecode opaco, e ogni tentativo di osservare il runtime che lo interpreta fa scattare un controllo di integrità. Dal solo file, il deoffuscamento automatico tramite IA diventa impraticabile. Per rafforzare ulteriormente il codice: racchiudere le funzioni sensibili in una IIFE affinché i nomi vengano trasformati completamente e abilitare opzioni di hardening come la crittografia del bytecode. Maggiori informazioni su come la VM trasforma il codice.

L'offuscamento VM è una tecnologia complessa e alcuni casi limite potrebbero non essere pienamente supportati. Se il codice smette di funzionare dopo l'offuscamento VM, è possibile circoscrivere il problema utilizzando vmTargetFunctionsMode: 'comment' per offuscare selettivamente funzioni specifiche. Per istruzioni passo per passo su come individuare il codice problematico e segnalare il problema, consultare la guida alla risoluzione dei problemi.

L'offuscatore introduce nuovo codice per proteggere da debug e reverse engineering. Le stringhe vengono convertite in formato esadecimale e, con l'offuscamento VM, un intero interprete di macchina virtuale viene incluso insieme al bytecode. Le dimensioni non sono un aspetto particolarmente critico: il codice offuscato si comprime molto bene con GZIP, attivo per impostazione predefinita sulla maggior parte dei server.

Qualsiasi offuscamento ha un certo impatto sulle prestazioni. L'offuscamento standard comporta un sovraccarico minimo. L'offuscamento VM ha un impatto molto maggiore e fortemente dipendente dal codice: ad esempio, il codice convertito in bytecode con molta ricorsione risulta sensibilmente più lento. In media il preset low comporta un impatto di circa 10x, mentre il preset anti-LLM con Self Defending e Debug Protection è circa 12x più lento. È possibile calibrare il compromesso modificando le opzioni oppure applicando l'offuscamento VM solo alle sezioni di codice sensibili. Per suggerimenti di ottimizzazione consultare la guida alle best practice.

No, non è consigliato e in alcuni casi comprometterebbe il codice (soprattutto se è abilitato self-defending). È però possibile passare il codice attraverso un minificatore prima dell'offuscamento.

Per i file di dimensioni inferiori a 4.4 MB, il sorgente viene elaborato interamente in memoria e restituito immediatamente come output offuscato. Per i file più grandi (piani Team e Business), i file vengono caricati temporaneamente su uno storage sicuro ed eliminati subito dopo il completamento dell'offuscamento. Come ulteriore misura di sicurezza, un processo di pulizia viene eseguito ogni 5 minuti per rimuovere qualsiasi file più vecchio di 5 minuti. Il codice non viene mai conservato.

No, non è possibile riportare il codice offuscato al codice originale: conservare quindi l'originale in un luogo sicuro.

Sì. È possibile selezionare "Node" come target nelle opzioni di offuscamento per ottimizzare l'output per gli ambienti Node.js.

Supportiamo ES2015 (ES6) e tutte le funzionalità JavaScript moderne, tra cui la sintassi ES2022+, i campi privati di classe, async/await, l'optional chaining e altro ancora. TypeScript e JSX devono essere compilati in JavaScript prima dell'offuscamento. Con un piano a pagamento è possibile offuscare anche i file HTML: aggiungere l'attributo data-javascript-obfuscator ai tag <script> da proteggere e ciascuno verrà offuscato singolarmente, preservando la struttura HTML. Il codice di ogni script contrassegnato deve essere autonomo (senza riferimenti ad altri script) e gli script di tipo modulo ES vengono ignorati.

L'output offuscato, incluso l'interprete VM e il livello Self Defending, è attivamente supportato e testato sui browser desktop evergreen e su iOS 16+ (all'incirca gli ultimi 3 anni). I browser meno recenti sono supportati con un approccio best-effort fino a un limite minimo dato dal supporto dei moduli ES2015; tutto ciò che si colloca al di sotto, Internet Explorer compreso, non rientra nell'ambito supportato.

Consultare i piani e i prezzi per la protezione VM oppure provare l<playground>area di prova online gratuita</playground> per loffuscamento standard. Per una panoramica completa leggere la guida introduttiva.

pricing.faq.usageMeasured.answer

pricing.faq.exceedLimit.answer

pricing.faq.upgradeDowngrade.answer

pricing.faq.cancel.answer

pricing.faq.paymentMethods.answer