Browser Environment

The browserEnvironment option declares facts about the environment your production build is served in, so the protected code can bind or react to them. It is a small object, and each field takes effect together with one specific protection - on its own the option does nothing:

transport

The scheme your production serves the bundle over - 'http' or 'https'. Takes effect with vmSelfDefending.

With 'https', a copy a reverse engineer serves over plain HTTP will not run correctly. 'http' or an unset field adds no such protection.

A build declared transport: 'https' runs correctly only where it is actually served over https:. Every other scheme corrupts it, so declare it only when every context that loads your production build is HTTPS. That excludes:

• plain http://, including http://localhost in development;
• file:// - Electron, Cordova, and other packaged apps;
• blob: and about: embeddings - a bundle running inside an about:blank or srcdoc iframe.

A client-side HTTP→HTTPS redirect still renders the HTTP page first, so the bundle must not run before the redirect completes.

hosting

Where your production bundle is served from - 'remote' or 'local'. Takes effect with vmDebugProtection, on the browser and browser-no-eval targets only. Requires obfuscator version 7.14.0 or later.

With 'remote', a copy a reverse engineer lifts and runs in their own local setup is treated as a runtime-environment mismatch, and the automation defenses react as configured by vmDefenseReaction. 'local' or an unset field adds no such protection.

A build declared hosting: 'remote' runs correctly only when it is loaded from a remote host. A bundle opened from a local setup - localhost, a dev server, file:// - is treated as a mismatch by design, so declare it only when every context that loads your production build is served remotely, and keep it off the builds you use for local development, testing, and CI.

hookedBuiltins

Set to true to declare that the runtime your production build runs in legitimately replaces native builtins with JavaScript wrappers - the app's own anti-tamper, the host page, or other browser extensions sharing the same realm. Takes effect with vmSelfDefending. Requires obfuscator version 7.15.0 or later.

Self Defending normally treats a replaced native builtin as tampering and stops the build from running. With hookedBuiltins: true, it tolerates such an environment and the protected code still runs. false or an unset field keeps the strict behavior.

hookedBuiltins deliberately relaxes tamper detection: once it is set, an analyst who wraps those same builtins to inspect your code is no longer stopped either. The VM virtualization, anti-debugging, and integrity protections are unaffected. Enable it only when your production runtime is known to hook builtins and that weaker guarantee is acceptable.

Supported targets

browserEnvironment applies only to the browser, browser-no-eval, and service-worker targets. It is rejected for node, userscript, and bytenode - obfuscation fails with a validation error rather than silently dropping the setting. hosting is narrower still: it is accepted on a service worker but binds nothing there.

In the dashboard, the Transport, Hosting, and Hooked Builtins controls live in the Advanced Protection panel. Each becomes editable once the protection it pairs with is on - VM Self Defending for Transport and Hooked Builtins, VM Debug Protection for Hosting - and the target supports it.

Requirements

• transport and hookedBuiltins take effect with vmSelfDefending, hosting with vmDebugProtection; none of them does anything otherwise.
• A browser, browser-no-eval, or service-worker target (browser or browser-no-eval for hosting).
• Obfuscator version 7.9.0 or later for transport, 7.14.0 or later for hosting, 7.15.0 or later for hookedBuiltins.

Example