Browser Environment

Section

Pro

v7.9.0+

Declare como seu build de produção é servido para que o código protegido possa vincular a ele sua integridade.

A opção browserEnvironment declara fatos sobre o ambiente em que seu build de produção é servido, para que o código protegido possa se vincular a eles ou reagir a eles. É um objeto pequeno, e cada campo só tem efeito em conjunto com uma proteção específica — sozinha, a opção não faz nada:

browserEnvironment: { transport: 'https', hosting: 'remote' }

`transport`

O esquema pelo qual sua produção serve o bundle: 'http' ou 'https'. Tem efeito com vmSelfDefending.

Com 'https', uma cópia que um engenheiro reverso sirva por HTTP simples não funcionará corretamente. 'http' ou um campo não definido não adiciona essa proteção.

Um build declarado com transport: 'https' funciona corretamente apenas onde é de fato servido por https:. Qualquer outro esquema o corrompe, então declare isso somente quando todos os contextos que carregam seu build de produção usarem HTTPS. Isso exclui:

http:// simples, incluindo http://localhost em desenvolvimento;
file:// — Electron, Cordova e outros apps empacotados;
incorporações blob: e about: — um bundle executando dentro de um iframe about:blank ou srcdoc.

Um redirecionamento HTTP→HTTPS no lado do cliente ainda renderiza primeiro a página HTTP, portanto o bundle não pode ser executado antes de o redirecionamento terminar.

`hosting`

De onde seu bundle de produção é servido: 'remote' ou 'local'. Tem efeito com vmDebugProtection, e apenas nos targets browser e browser-no-eval. Requer o ofuscador na versão 7.14.0 ou posterior.

Com 'remote', uma cópia que um engenheiro reverso extrai e executa em seu próprio ambiente local é tratada como uma divergência do ambiente de execução, e as defesas contra automação reagem conforme configurado em vmDefenseReaction. 'local' ou um campo não definido não adiciona essa proteção.

Um build declarado com hosting: 'remote' funciona corretamente somente quando é carregado de um host remoto. Um bundle aberto a partir de um ambiente local — localhost, um servidor de desenvolvimento, file:// — é tratado como divergência por design, então declare-o apenas quando todos os contextos que carregam seu build de produção forem servidos remotamente, e deixe-o fora dos builds usados para desenvolvimento local, testes e CI.

Targets suportados

browserEnvironment aplica-se apenas aos targets browser, browser-no-eval e service-worker. Para node, userscript e bytenode a opção é rejeitada — a ofuscação falha com um erro de validação em vez de descartar silenciosamente a configuração. hosting é ainda mais restrito: é aceito em um service worker, mas não vincula nada ali.

No painel, os controles Transport e Hosting ficam na seção Advanced Protection. Cada um só se torna editável quando a proteção correspondente está ativada — VM Self Defending para Transport, VM Debug Protection para Hosting — e o target o suporta.

Requisitos

transport tem efeito com vmSelfDefending, e hosting com vmDebugProtection; caso contrário, nenhum dos dois faz nada.
Um target browser, browser-no-eval ou service-worker (browser ou browser-no-eval para hosting).
Ofuscador na versão 7.9.0 ou posterior para transport, 7.14.0 ou posterior para hosting.

Exemplo

JavaScriptObfuscator.obfuscate(code, {
    vmObfuscation: true,
    vmSelfDefending: true,
    vmDebugProtection: true,
    target: 'browser',
    browserEnvironment: { transport: 'https', hosting: 'remote' }
});

VM Domain Lock

Usando o pacote NPM