As ferramentas de inspeção de rede, integradas aos navegadores modernos, permitem que os desenvolvedores monitorem e depurem o tráfego web, o carregamento de recursos e problemas de segurança. Embora sejam essenciais para o desenvolvimento e a depuração, essas ferramentas também podem ser usadas por atacantes para analisar aplicações. As medidas de segurança devem levar em conta as informações expostas por essas ferramentas.
As ferramentas de inspeção de rede são os painéis embutidos nas ferramentas de desenvolvedor de um navegador, como a aba Network no Chrome DevTools ou no Firefox, que registram cada requisição que uma página faz. Para cada requisição, elas mostram a URL, o método, o status, os cabeçalhos, o tempo, o payload, os cookies e o corpo da resposta, permitindo que o desenvolvedor veja exatamente o que a página buscou e em que ordem. Elas se combinam com painéis relacionados para o DOM, o console, o armazenamento e a depuração de JavaScript. As ferramentas não têm privilégios: mostram apenas o que a página atual e a própria sessão da pessoa já podem acessar, e são executadas inteiramente no cliente. São indispensáveis para construir e depurar aplicações web e para diagnosticar problemas de desempenho e de segurança.
Como o inspetor expõe tudo o que o navegador vê, ele também é uma ferramenta de reconhecimento. Qualquer pessoa pode abri-lo e ler os endpoints de API que um site chama, o formato de suas requisições, os tokens e cookies em uso e qualquer segredo que um desenvolvedor tenha enviado por engano ao cliente. Este é um primeiro passo rotineiro ao sondar uma aplicação web: mapear o tráfego e, então, repetir ou adulterar requisições. O ponto importante é que o inspetor não concede novo acesso; ele apenas revela o que o cliente já possui. Portanto, o risco não é a ferramenta, mas a suposição de que o código ou os dados do lado do cliente estão ocultos. Tudo o que é enviado ao navegador, incluindo campos de formulário ocultos e lógica minificada, é totalmente visível para o usuário.
A lição defensiva é projetar como se toda requisição e resposta do lado do cliente fosse pública, porque, para o usuário, ela é. Nunca confie na obscuridade: mantenha segredos, chaves de assinatura e lógica de autorização no servidor, aplique cada verificação de acesso no lado do servidor e presuma que o JavaScript minificado ou ofuscado pode ser lido. Envie ao navegador apenas os dados que um determinado usuário tem direito de ver e limite o escopo dos tokens de forma restrita. A ofuscação pode aumentar o esforço da análise, mas nunca substitui um controle real. Nada disso é algo que um terceiro possa bloquear por você: é uma propriedade de como você constrói a aplicação. Tratar o inspetor de rede como uma parte permanente e legítima do navegador de todo visitante leva a designs mais honestos e mais seguros.
Não de forma eficaz. Scripts que tentam detectar ou bloquear as DevTools são facilmente contornados e, na maioria das vezes, apenas frustram usuários legítimos. Como as ferramentas são executadas no próprio navegador do usuário, você não pode desativá-las de forma confiável. A resposta duradoura é construir de modo que nada sensível seja exposto ao cliente em primeiro lugar.
Não. As requisições de toda aplicação web são visíveis no inspetor por design, e isso, por si só, não é uma falha. Só se torna um problema se essas requisições revelarem segredos ou se o servidor confiar no cliente para aplicar suas próprias permissões. Uma API bem construída permanece segura mesmo quando é totalmente observada.
We answer client-side security questions every day. Bring yours.