O Web Assembly é um formato de instruções binárias para máquinas virtuais baseadas em pilha que permite a execução de código com alto desempenho nos navegadores web. Embora rode em um ambiente com sandbox, as questões de segurança incluem a validação adequada de entradas e a segurança de memória. Os módulos Wasm devem ser tratados com o mesmo rigor de segurança que qualquer outro código client-side.
O WebAssembly, muitas vezes abreviado para Wasm, é um formato binário e portátil de instruções para uma máquina virtual baseada em pilha que corre nos navegadores web ao lado do JavaScript. Linguagens como C, C++ e Rust compilam para módulos Wasm compactos que executam a uma velocidade quase nativa, o que o torna bem adequado a trabalho intensivo em CPU, como processamento de vídeo, jogos, criptografia e ferramentas de CAD no navegador. O Wasm não substitui o JavaScript; os dois interoperam, com o JavaScript normalmente a carregar um módulo e a chamar as suas funções exportadas, enquanto o módulo chama de volta funções de host importadas. Os módulos correm dentro da mesma sandbox do navegador que o script da página e, por conceção, não têm acesso direto ao DOM, ao sistema de ficheiros ou à rede, exceto através do JavaScript e das APIs do navegador.
A sandbox e o modelo de memória linear dão ao WebAssembly uma base sólida: um módulo não consegue ir além da sua própria memória nem chamar capacidades arbitrárias do host sem uma importação explícita. Mas o Wasm continua a ser código, e a sua forma binária torna-o muito mais difícil de rever, tanto para humanos como para muitos scanners, do que JavaScript legível, algo que os atacantes exploram para esconder lógica como cryptominers ou rotinas de skimming ofuscadas. Bugs de segurança de memória no C ou C++ original podem sobreviver à compilação e ser corrompidos dentro da memória do próprio módulo. E como o Wasm chega ao mundo exterior apenas através das suas ligações JavaScript, código de ligação fraco ou não validado entre os dois é um local comum por onde a injeção e o uso indevido se conseguem infiltrar.
Trate os módulos Wasm com o mesmo escrutínio que qualquer outro código do lado do cliente: construa-os a partir de código-fonte em que confia, fixe e verifique o que envia, e aplique Subresource Integrity ao carregar módulos a partir de um CDN, para que um binário adulterado seja rejeitado. Valide todos os dados que cruzam a fronteira entre JavaScript e Wasm em ambos os sentidos, e mantenha a página envolvente sob uma Content Security Policy rigorosa, que rege de onde o Wasm pode ser instanciado. Compile com as mitigações de segurança de memória que a sua toolchain oferece. O WebAssembly é uma tecnologia neutra da plataforma web, por isso a cside não está ligada a ele em específico; quando um payload Wasm malicioso ou oculto chega através de um script third-party, o proxy e a análise de payload da cside conseguem detetar e bloquear o comportamento desse script.
Corre na mesma sandbox do navegador, com um modelo de memória que limita o que um módulo consegue alcançar, o que é uma base sólida. Mas o seu formato binário é mais difícil de auditar do que o JavaScript, por isso lógica maliciosa consegue esconder-se com mais facilidade, e bugs de memória da linguagem de origem podem persistir. Mais seguro nalguns aspetos, não em todos.
Não. Um módulo Wasm não tem acesso direto ao DOM, ao sistema de ficheiros ou à rede. Só chega ao mundo exterior através do JavaScript e das APIs do navegador que lhe são explicitamente concedidas como importações. Essa fronteira é uma força de segurança, mas o código de ligação JavaScript à volta dela ainda tem de validar o que passa por ali.
We answer client-side security questions every day. Bring yours.