Deno e permissões: como limitar o acesso de scripts a arquivos e rede

O que é o modelo de permissões do Deno

Deno é um runtime para JavaScript e TypeScript criado por Ryan Dahl, o mesmo criador original do Node.js. Uma diferença conhecida é a postura de segurança: o programa não recebe acesso amplo ao computador sem uma permissão explícita.

Um script pode executar código, mas não pode simplesmente ler qualquer arquivo, abrir conexões de rede ou iniciar um processo externo. O acesso precisa ser concedido de forma ampla ou restrita a um caminho, domínio ou variável.

Esse modelo é útil para automação, ferramentas de linha de comando e aplicações que precisam deixar claro quais recursos usam. Ele não elimina todo risco, mas reduz o impacto de código inesperado ou de uma dependência comprometida.

Como funciona

O Deno possui permissões para leitura, escrita, rede, variáveis de ambiente, subprocessos, informações do sistema, imports remotos e FFI. Sem a permissão correspondente, a operação é bloqueada.

As permissões podem ser específicas. Em vez de liberar toda a rede, você pode autorizar um host. Em vez de liberar todo o disco, pode conceder leitura apenas a uma pasta de dados.

O bloqueio aparece como erro quando o código tenta realizar uma operação não autorizada. Isso também ajuda a descobrir dependências que acessam recursos fora do que o projeto pretendia usar.

Principais permissões

A permissão --allow-read controla leitura de arquivos e diretórios, enquanto --allow-write controla a escrita. Ambas podem receber caminhos específicos.

--allow-net controla conexões de rede e pode ser limitado a hosts e portas. --allow-env controla variáveis de ambiente, importantes quando carregam tokens e strings de conexa£o.

--allow-run controla subprocessos. As permissões --allow-sys, --allow-import e --allow-ffi atendem casos especializados e exigem análise cuidadosa.

• Arquivos: use somente os diretórios necessários.
• Rede: autorize apenas APIs e bancos usados.
• Ambiente: exponha somente as variáveis necessárias.

Como começar: execução com menor privilégio

Instale o Deno pelo método da documentação oficial e confirme a versão. Depois, execute o script sem permissões extras para observar quais operações ele precisa.

deno --version
deno run script.ts

Se o script precisar ler uma pasta de configuração e chamar uma API, conceda somente esses acessos. O exemplo abaixo evita liberar o disco e a rede inteira.

deno run --allow-read=./config --allow-net=api.exemplo.com script.ts

Para uma variável de ambiente, libere apenas o nome usado. Evite autorizar todo o ambiente quando o processo conhece uma única configuração.

deno run --allow-env=API_URL --allow-net=api.exemplo.com script.ts

Exemplo prático: uma consulta a API

Considere um script que lê a URL de uma API e busca dados. Ele precisa de acesso à variável API_URL e de rede para o domínio autorizado, mas não precisa ler arquivos ou executar processos.

const url = Deno.env.get("API_URL");
const response = await fetch(url);
console.log(await response.json());

Uma execução coerente pode liberar a variável e o host específico. Se o código tentar ler um arquivo, a falta de permissão revelará que a implementação ou o comando precisa ser revisado.

deno run --allow-env=API_URL --allow-net=api.exemplo.com script.ts

Em automações, mantenha o comando de execução junto do projeto. Assim, a equipe consegue revisar quais capacidades o programa recebe.

Comparação com alternativas

No Node.js, o processo normalmente começa com acesso aos recursos permitidos pelo usuário do sistema. É possa­vel aplicar isolamento com containers e usuários restritos, mas isso exige outra camada.

Em navegadores, JavaScript roda com APIs limitadas pelo modelo de segurança da página. Deno combina a flexibilidade de um runtime de servidor com permissões explícitas para operações sensíveis.

Containers continuam importantes quando o risco exige isolamento de sistema de arquivos, rede ou usuário. As permissões do Deno são uma camada no processo e não substituem controles do sistema operacional.

• Script local simples: permissões do Deno podem bastar.
• Servia§o de produção: combine Deno com usuário restrito e isolamento.
• Ambiente multi-tenant: use camadas adicionais.

Pontos positivos e limitações

O maior benefício é tornar acessos sensíveis explícitos. A equipe consegue ver no comando se um script pode acessar rede, disco, ambiente ou subprocessos.

O modelo também ajuda na investigação de dependências. Se uma biblioteca tentar acessar algo inesperado, a operação falha em vez de receber acesso silencioso.

A limitação é operacional: permissões precisam ser mantidas quando o programa cresce. Uma permissão ampla ainda pode permitir ações perigosas dentro da categoria liberada, e o runtime não substitui validação de entrada.

Casos de uso reais

Scripts de migração podem receber leitura de configuração, acesso a uma pasta de relatórios e rede apenas para o banco da tarefa.

Ferramentas de linha de comando podem liberar escrita em um diretório de saída sem ganhar acesso a documentos pessoais ou chaves de outras pastas.

Jobs de CI podem receber somente variáveis necessárias e hosts usados no build. Isso reduz o alcance de um passo inesperado.

Servia§os que chamam APIs externas podem separar rede, arquivos e ambiente. Cada permissão vira uma decisão revisável.

Dicas e boas práticas

Revise dependências e atualize o runtime. Permissões reduzem alcance, mas não corrigem uma biblioteca vulnerável ou uma validação fraca.

Separe permissões de leitura e escrita quando possa­vel. Um programa que consulta dados não deve ganhar autorização para alterar a mesma pasta.

Use usuários do sistema, containers e políticas de rede quando a aplicação processar dados de terceiros ou operar em produção.

Vale a pena usar esse modelo?

Sim, especialmente para scripts e ferramentas que acessam recursos variados. A exigência de permissão explícita melhora a revisão e reduz acessos acidentais.

Ele não é uma barreira completa. Um programa autorizado a escrever em uma pasta ainda pode causar dano naquela pasta, e uma rede autorizada ainda exige autenticação.

O próximo passo é executar um script real sem permissões, registrar os bloqueios e transformar cada necessidade em autorização mínima. Depois, revise os comandos junto do código.