GitHub

Toda plataforma de sucesso chega num ponto onde precisa deixar outros escreverem código que roda dentro dela. Plugins de usuário, funções customizadas de clientes enterprise, extensões de parceiros, regras de negócio enviadas via API. O problema é sempre o mesmo: como você executa código que não escreveu, em infraestrutura que você controla, sem transformar essa abertura numa vulnerabilidade? As respostas tradicionais são caras, lentas ou frágeis. WebAssembly oferece uma resposta diferente — e entender por que requer entender o que torna o problema difícil.

Por que as soluções tradicionais não escalam

A primeira tentativa de muitos times é eval() ou equivalente: executar a string de código diretamente no runtime. É rápido de implementar e catastrófico de manter. O código do plugin tem acesso a tudo que o processo hospedeiro tem — memória, rede, sistema de arquivos. Um plugin malicioso ou simplesmente defeituoso pode derrubar o processo inteiro ou exfiltrar dados de outros tenants.

A segunda tentativa é microserviço por plugin: cada extensão roda num container isolado. Funciona do ponto de vista de segurança, mas o custo operacional cresce linearmente com o número de plugins. Manter um container por cliente é inviável em plataformas com centenas de extensões. A latência de cada chamada cross-container também penaliza operações que deveriam ser sub-milissegundo.

Processos filhos com namespaces de Linux são outra opção — mais leves que containers, mas com overhead de inicialização e complexidade de seccomp e cgroups para garantir isolamento real. Requer uma equipe que entenda profundamente o modelo de kernel. O problema comum a todas essas abordagens é que tratam o isolamento como algo externo: você constrói uma cerca em volta do código não confiável usando mecanismos do sistema operacional. Wasm inverte essa lógica.

O modelo de capacidades: zero por padrão

Um módulo WebAssembly começa com zero capacidades. Literalmente nenhuma. Ele não consegue abrir um arquivo. Não consegue fazer uma requisição de rede. Não consegue ler variáveis de ambiente. Não consegue acessar nenhum byte fora da sua própria memória linear. Se o módulo tentar qualquer dessas operações sem que o host tenha explicitamente disponibilizado a interface correspondente, a operação falha — não em runtime com uma exceção, mas estruturalmente, porque a função que o módulo chama simplesmente não existe no ambiente de execução.

Isso é chamado de segurança baseada em capacidades, e é conceitualmente diferente do modelo de autoridade ambiente que o código nativo herda. Quando você carrega uma biblioteca nativa, ela corre com todos os privilégios do processo. Quando você carrega um módulo Wasm, ele começa sem privilégio nenhum e você, como host, decide o que entregar.

A interface de segurança fica no código de integração do host. Você expõe ao módulo exatamente as funções que fazem sentido — acesso à API do canvas do Figma, mas não ao sistema de arquivos; acesso aos dados do pedido no Shopify, mas não às credenciais de banco de dados. O módulo faz tudo que você permitiu, e nada mais. A superfície de ataque é declarada explicitamente, não inferida.

Como plataformas reais usam isso

O Figma é o exemplo mais conhecido. O sistema de plugins roda cada plugin dentro de um sandbox Wasm. O plugin recebe acesso à API do canvas — pode ler e modificar elementos, criar layers, acessar propriedades de texto — mas não tem acesso a nada fora daquele contrato. Um plugin não consegue ler arquivos do sistema operacional nem fazer chamadas de rede arbitrárias. Isso não é política de uso; é impossibilidade técnica. É por isso que você pode instalar um plugin Figma de um desenvolvedor desconhecido com razoável confiança de que ele não vai exfiltrar seus arquivos.

O Shopify tomou decisão parecida com o Shopify Functions: lógica customizada de desconto, validação de carrinho e regras de frete é enviada pelos merchants como módulos Wasm. Cada invocação recebe os dados do pedido, executa dentro de limites estritos de CPU e memória por chamada, e retorna o resultado. Um merchant com código mal escrito não derruba a plataforma nem acessa dados de outros merchants.

O Envoy Proxy usa o mesmo modelo para filtros de tráfego customizados. Empresas que operam Envoy como proxy — Istio e AWS App Mesh são exemplos — podem escrever filtros Wasm que processam requests e responses em trânsito. O filtro tem acesso aos headers e ao body, mas nada do estado interno do proxy. Extensibilidade sem abrir o núcleo do sistema. Game engines chegaram ao mesmo modelo por caminhos independentes: sistemas de modding que permitem jogadores adicionarem conteúdo precisam rodar código de estranhos sem comprometer o jogo hospedeiro, e Wasm resolve isso com o mesmo mecanismo de capacidades.

O custo para quem escreve plugins

Essa segurança tem um preço. Escrever um plugin para uma plataforma baseada em Wasm é mais difícil do que escrever JavaScript ou Python.

A primeira fricção é a toolchain: compilar para Wasm exige um compilador compatível — Rust e C/C++ têm suporte maduro, Go tem suporte experimental, Python e Ruby chegam com limitações. A segunda é o acesso a sistema: dentro do sandbox, não existe acesso direto a nada além do que o host expôs. Bibliotecas que fazem chamadas HTTP diretas não funcionam se o host não disponibilizou a interface correspondente. Isso força disciplina de design que pode ser frustrante no começo.

Do lado da plataforma, a complexidade fica em definir bem a API exposta ao módulo. Uma API mal desenhada é restritiva demais — plugins não fazem o que precisam — ou permissiva demais, comprometendo a segurança. Esse contrato é trabalho de produto e segurança tanto quanto de engenharia.

Quando faz sentido investir nesse modelo

A decisão tem um perfil claro. Faz sentido quando você está construindo uma plataforma com desenvolvedores externos cuja qualidade de código você não pode garantir. Faz sentido quando precisa de personalização por tenant com limites individuais de recurso — cada cliente tem sua lógica, mas nenhum monopoliza CPU ou memória. Faz sentido quando você distribui código que vai rodar em infraestrutura que não controla completamente.

Não faz sentido quando os plugins são internos e você confia na equipe que os escreve. Overhead de toolchain e restrições de sistema criam atrito real sem contrapartida quando a ameaça que você quer mitigar não existe no seu modelo. A linha é essa: extensibilidade para fora, para um público que você não controla, é onde Wasm entrega.

Wasm para plugins e sandbox: rodando código de terceiros com segurança

Por que as soluções tradicionais não escalam

O modelo de capacidades: zero por padrão

Como plataformas reais usam isso

O custo para quem escreve plugins

Quando faz sentido investir nesse modelo

Leia também