Auditoria de segurança de site: como verificar login, permissões e HTTPS

1. Siga as proteções ao longo de uma jornada real

Comece por uma tarefa que importa para quem usa o site: criar uma conta, consultar um pedido ou abrir um chamado no suporte. Liste as páginas, os serviços e os dados envolvidos em cada passo. Isso dá foco à revisão e liga o trabalho técnico a algo que os clientes usam de verdade.

Ao longo da jornada, cada camada tem um papel. A rede deixa acessíveis apenas os serviços previstos. A aplicação reconhece a conta e aplica as permissões. O navegador recebe o conteúdo por uma conexão criptografada e segue as políticas que chegam nas respostas. Hospedagem, bibliotecas e serviços de terceiros sustentam tudo isso em segundo plano. O guia de testes de segurança web da OWASP (WSTG) organiza essas camadas em uma estrutura que ajuda a não esquecer nenhuma delas.

Antes de começar, defina o escopo por escrito: quais domínios e subdomínios entram, quais contas de teste serão usadas e quem autorizou a revisão. Revise apenas sites que são seus ou que você tem autorização para testar e, quando um teste puder alterar dados, prefira o ambiente de homologação.

2. Relacione cada proteção a um resultado concreto

Esses resultados ajudam a definir prioridades. Uma jornada de conta usada por muitos clientes costuma merecer atenção primeiro. Um componente compartilhado, como o formulário de login ou a configuração de sessão, também vale a revisão, porque uma boa prática aplicada ali se espalha por muitas páginas. Priorize pelo que cada correção protege e por quantas páginas ela alcança.

3. Dê às contas uma experiência coerente

A autenticação estabelece qual conta está usando o serviço; a autorização decide o que essa conta pode fazer e quais dados pode ver. Descreva as regras em linguagem comum: a cliente vê apenas as próprias notas fiscais, o atendente cuida dos chamados atribuídos a ele e o administrador gerencia as configurações da equipe. Essa descrição vira um plano de teste. Para cada regra, tente a ação com uma conta que deveria conseguir e com outra que não deveria. Um teste simples: com a conta de teste A, abra um pedido, troque na URL o número do pedido pelo de um pedido da conta de teste B e confirme que o servidor recusa. As orientações de autorização da OWASP pedem que a permissão seja validada em toda requisição, e não só na tela que exibe o botão.

Revise cadastro, login, verificação de e-mail, recuperação de senha e logout como uma experiência única. Deixe os gerenciadores de senha funcionarem, sem impedir que a pessoa cole a senha no campo, use rótulos claros nos formulários e responda com mensagens genéricas, que não revelem se um e-mail está cadastrado. Quando a autenticação multifator fizer sentido para a conta, ofereça uma ativação e uma recuperação fáceis de entender; a OWASP a descreve como a melhor defesa contra a maioria dos ataques ligados a senhas. As orientações de autenticação da OWASP explicam os controles por trás disso.

Depois do login, a aplicação deve gerar um identificador de sessão novo e, no logout, invalidar a sessão no servidor, e não apenas apagar o cookie no navegador. É o que recomendam as orientações de gestão de sessão da OWASP. Teste tudo com contas dedicadas, uma para cada papel, e com dados de exemplo fáceis de reconhecer.

4. Registre observações técnicas que todos entendam

Uma boa revisão registra o que foi inspecionado e o que aconteceu. Anote a página ou o serviço exato, o valor relevante da resposta, o comportamento esperado e os passos seguidos. Nas notas compartilhadas, use dados de exemplo e mascare senhas, tokens e chaves. Assim, desenvolvimento, suporte e quem revisar depois trabalham com a mesma referência.

Agrupe as observações pelo componente responsável. Várias páginas podem usar a mesma configuração de sessão, e vários testes de rede podem descrever um único serviço. Em um site público, o HTTPS costuma usar a porta 443, e a porta 80 existe para levar o visitante ao endereço HTTPS. O guia de TLS da MDN recomenda que esse redirecionamento leve ao mesmo recurso em HTTPS, sem trocar de host no primeiro passo. Anotar a finalidade de cada serviço transforma uma lista de detalhes técnicos em um mapa que faz sentido.

Dê a cada observação o peso certo. Um cabeçalho Server que mostra a versão do software, por exemplo, não é uma vulnerabilidade por si só, como lembra o WSTG da OWASP; o que mais pesa é manter esse software atualizado. Registre também as verificações que passaram, ao lado dos pontos a acompanhar, para que a revisão mostre as proteções que já funcionam.

5. Leve as boas práticas para o desenvolvimento do dia a dia

Use componentes de autenticação consolidados, consultas parametrizadas ao banco de dados e verificação de permissões no servidor, nunca só na interface. Guarde senhas de serviço, chaves de API e tokens em um cofre de segredos, fora do código-fonte, com responsável e processo de renovação definidos. Configure os cookies de sessão de acordo com a jornada real:

• Secure, para que o navegador só envie o cookie por HTTPS.
• HttpOnly, para que o JavaScript da página não consiga ler o cookie, por exemplo via document.cookie. O cookie não fica criptografado e continua sendo enviado ao servidor normalmente; o atributo dificulta o roubo da sessão em caso de XSS, mas não impede o XSS.
• SameSite definido de forma explícita, porque os navegadores não usam todos o mesmo valor padrão.

A referência da MDN sobre Set-Cookie detalha cada atributo, e a referência de cabeçalhos HTTP da OWASP explica como as políticas do navegador completam essa base.

Mantenha um registro curto de serviços com finalidade, responsável, versão do software e forma de atualização. Quando a equipe adicionar um meio de pagamento ou um widget de atendimento, inclua o serviço no registro e percorra a jornada relacionada. Planeje as atualizações e mantenha à mão a última configuração que funcionava, para poder voltar atrás se for preciso. Um conjunto pequeno de práticas, aplicado do mesmo jeito em todos os modelos de página, vira um padrão comum para todos que constroem o site.

6. Crie um ritmo de revisão que se repete

Defina uma linha de base e repita as mesmas verificações depois de cada mudança relevante. Use o mesmo alvo, o mesmo papel e a mesma jornada, para que as comparações façam sentido. Em permissões, confirme que cada conta de teste recebe exatamente o acesso previsto, nem mais nem menos. Para as políticas do navegador, percorra os mesmos formulários e os mesmos retornos de sites externos que os visitantes usam, como pagamento e login social.

1. Registre as páginas, os papéis e as ações incluídos na revisão.
2. Examine as respostas do servidor e anote certificado, cabeçalhos e cookies observados.
3. Complete a jornada prevista com contas de teste representativas.
4. Anote o resultado, a pessoa responsável e a data da próxima revisão.

Boas ocasiões para revisar são mudanças de hospedagem, de autenticação, dos modelos compartilhados ou dos serviços conectados. Um registro datado ajuda quem chega à equipe a entender o raciocínio por trás da configuração. Com o tempo, essa rotina forma um histórico prático de como o site é mantido e de como as ações importantes dos clientes são protegidas.

7. Comece com uma primeira revisão pequena

Escolha uma página pública e uma tarefa da área do cliente e descreva as proteções de cada uma em um checklist curto: quem pode fazer o quê, quais dados aparecem e o que o navegador recebe. Para a parte pública, o snapshot gratuito de prontidão para lançamento do Sitelemetry roda oito verificações passivas em uma origem pública, sem cadastro: resolução DNS, políticas de e-mail e de certificados no DNS, certificado TLS, cabeçalhos de segurança, uso de HTTPS (HSTS e conteúdo misto; o redirecionamento de HTTP para HTTPS só é testado quando você digita um endereço com http://), sinais de tecnologia, entrega (cache, compressão e CDN) e situação do registro do domínio. Ele não é um pentest e não substitui a revisão de contas e permissões descrita acima.

Para aprofundar a camada de conexão, veja o guia do certificado SSL/TLS e do HTTPS; para ler e corrigir os cabeçalhos que o site envia, o guia para verificar os cabeçalhos de segurança HTTP; para o domínio e o e-mail, o guia de SPF, DKIM e DMARC. Antes de colocar um site novo no ar ou concluir uma migração, o checklist de lançamento de site repassa essas configurações públicas item por item. Para olhar uma camada de cada vez, o verificador gratuito de cabeçalhos de segurança avalia oito cabeçalhos importantes na página inicial, e o verificador de SPF e DMARC consulta os registros de e-mail de um domínio.