A extensão que um desenvolvedor instalou há três anos provavelmente pode ler tudo o que eles fazem no navegador hoje.
Essa é a resposta curta à questão da privacidade. Uma extensão do navegador não é um ícone inofensivo da barra de ferramentas. Com as permissões apropriadas, ele tem acesso total a todos os conteúdos de páginas da web, cookies e solicitações de rede. Ele pode ver todas as guias abertas, incluindo consoles de nuvem e até janelas anônimas, se o usuário tiver permitido que a extensão seja executada lá. Muitos incidentes de privacidade começam com uma permissão que foi concedida uma vez e nunca mais revisada.
Em geral conselhos de segurança online da VPNpro e guias semelhantes cobrem o lado da rede para permanecer seguro, mas não conseguem ver o que uma extensão faz dentro do navegador. Essa camada é mais responsabilidade do desenvolvedor. O risco é complicado, mas a solução é simples: solicite menos permissões, acesso mais restrito ao host e menos dados, e revise cada atualização. Aqui está um passo a passo de cada um.
Por que as extensões são diferentes
Um site é enquadrado pelo política de mesma origem. Ele não pode ler o conteúdo ou cookies de outro site. As extensões podem sair dessa caixa. Dependendo das permissões concedidas, é possível ler o conteúdo da página, injetar scripts, observar solicitações de rede e acessar cookies em todas as guias.
Pense no que um desenvolvedor abre em um dia normal: um console na nuvem, um painel de teste, um repositório privado, talvez webmail. Uma extensão com permissão excessiva vê tudo isso.
Um 2025 Estudo de segurança USENIX de 21 desenvolvedores de extensões descobriram que os desenvolvedores muitas vezes reconhecem os riscos de privacidade e segurança que suas extensões representam, mas muitas vezes não têm o conhecimento e os recursos para lidar com eles. Isso corresponde ao que muitos problemas de privacidade parecem na prática: não um autor mal-intencionado, mas um desenvolvedor bem-intencionado que envia software com configurações que ninguém revisou.
Comece com permissões, não com recursos
O erro mais comum é pedir acesso amplo antecipadamente e planejar reduzi-lo mais tarde. Mais tarde raramente chega.
Um manifesto como este deveria levantar as sobrancelhas:
{
"manifest_version": 3,
"permissions": ("tabs", "cookies", "history", "webRequest"),
"host_permissions": ("" )
}
Cada linha é uma decisão de privacidade. A história revela padrões de navegação. cookies com all_urls pode revelar dados da sessão em qualquer site. Se a extensão proteger apenas uma página, isso não será necessário. Um fluxo de trabalho melhor é começar sem permissões e adicioná-las uma de cada vez, justificando cada uma com uma breve declaração. Guia do Chrome sobre como as extensões declarar permissões explica as opções.
Um desenvolvedor que não consegue justificar uma permissão em uma frase curta provavelmente não deveria incluir a permissão na construção.
Limite o acesso ao host
As permissões de host merecem atenção própria porque definem até onde a extensão pode chegar. Alguns hábitos fazem uma diferença real:
- Liste os domínios exatos que o recurso precisa em vez de usar
- Usar aba ativa portanto, o acesso só se aplica quando o usuário clica na extensão.
- Mova as permissões não essenciais para opcionais, para que os usuários as aprovem no momento em que usarem o recurso relacionado.
Isso também ajuda na adoção. As pessoas hesitam quando uma extensão pede para ler todos os sites que visitam. Uma solicitação restrita parece e é mais confiável.
Tenha cuidado com os dados que saem do navegador
Análise e registro de erros são onde as boas intenções vazam. Um relatório de falha que inclui o URL completo da página pode conter um token de sessão na string de consulta. Um “evento de uso” pode capturar títulos de páginas de ferramentas internas.
A abordagem mais segura é coletar apenas os dados necessários para um recurso e processá-los localmente, se possível. Quando os dados precisam ser enviados, eles devem ser reduzidos ao mínimo absoluto. Evite enviar strings de consulta e trunque URLs para o nome de domínio sempre que possível. Nunca envie conteúdo da página se não for absolutamente necessário.
O código remoto é outra armadilha. Manifesto V3 restringe código hospedado remotamente por um bom motivo. Um script obtido em tempo de execução pode modificar seu comportamento após o fato e não é possível auditar o que ele fará no futuro. Agrupe tudo e o código revisado será idêntico ao código executado.
Finalmente, a política de privacidade deve corresponder à realidade. Precisa dizer claramente o que é coletado, por que e quem o recebe. Uma política vaga é um problema de confiança mesmo quando o código está limpo.
Observe a cadeia de suprimentos
Uma boa prorrogação hoje pode se tornar arriscada no próximo ano. Dois padrões continuam se repetindo.
Mudanças de propriedade. Extensões populares são vendidas e o novo proprietário envia uma atualização com rastreamento ou pior. O Grande Suspensoruma ferramenta de aba amplamente usada, acabou sinalizada como malware após uma mudança de mãos.
Contas de editores comprometidas. Se um invasor fizer phishing na conta do desenvolvedor, ele poderá enviar uma atualização maliciosa para todos os usuários existentes. Extensão do Cyberhaven foi atingido por uma conta de administrador fraudada no final de dezembro de 2024.
As defesas são em sua maioria enfadonhas, o que é um bom sinal. Autenticação de dois fatores com chave de hardware na conta do editor, uma pequena lista de pessoas com permissão para publicar e uma etapa de revisão antes de cada lançamento interromper a maior parte dela. Arquivos de bloqueio, versões fixadas e auditorias regulares de dependência cobrem o lado do código.
As equipes que instalam apenas extensões podem aplicar o mesmo pensamento. Mantenha uma lista de aprovados, revise as atualizações que alteram as permissões e remova tudo o que ninguém usa. Também vale a pena acompanhar as notícias de segurança, já que incidentes envolvendo extensões populares tendem a ser relatados publicamente.
Não se esqueça da máquina que o executa
A privacidade da extensão não para no manifesto. Os desenvolvedores costumam testar em cafés Wi-Fi ou redes compartilhadas, com compilações de depuração que registram muito mais do que a produção jamais faria. A proteção em nível de rede é uma camada sensata para isso, e os leitores que desejam obter informações básicas sobre ela podem encontrar guias gerais que cobrem criptografia, VPNs e hábitos de navegação mais seguros.
No entanto, é apenas uma camada. Uma VPN protege o tráfego em trânsito. Ele não faz nada em relação a um complemento que lê o conteúdo da página dentro do navegador, portanto, nunca substitui uma revisão de permissão adequada.
Hábitos mais simples fazem mais aqui. Um perfil de navegador separado para desenvolvimento mantém as extensões de teste longe de contas pessoais. Contas falsas ou de baixo privilégio para testes evitam expor credenciais reais. E os instaladores de qualquer ferramenta, incluindo clientes VPN, devem vir do site ou loja oficial, nunca de um espelho.
A conclusão
Extensões seguras se resumem à restrição. Peça menos acesso, colete menos dados, envie menos do dispositivo e explique mais ao usuário. Os desenvolvedores que tratam cada permissão como uma responsabilidade acabam com extensões nas quais as pessoas podem confiar, e as equipes que analisam o que instalam evitam as piores surpresas.
