403 Forbidden: causas, correções e bloqueios de bot que enganam monitores

403 contra 401

A RFC 9110 traça a linha com clareza. Um 401 Unauthorized significa que a autenticação é necessária ou que as credenciais enviadas não foram aceitas, e a resposta precisa trazer um cabeçalho WWW-Authenticate descrevendo como se autenticar. Um 403 Forbidden significa que o servidor se recusa a autorizar a requisição, e autenticar de novo não vai ajudar.

A especificação também permite que o servidor responda 404 em vez de 403 quando não quer revelar que o recurso sequer existe. É por isso que uma URL que você sabe estar lá pode voltar como "não encontrada" de um servidor endurecido. Se você está triando um 403, lembre que o caso inverso também existe.

O que produz um 403

• Permissões do sistema de arquivos. O processo do servidor web não consegue ler o arquivo ou atravessar o diretório. Clássico depois de uma cópia manual de arquivos ou de uma restauração que mudou o dono.
• Listagem de diretório desabilitada. Uma requisição a uma pasta sem arquivo de índice devolve 403 em servidores configurados para recusar listagens. Comportamento correto, erro confuso.
• Regras de autorização da aplicação. O usuário está logado mas não tem o papel, o plano ou a associação de tenant exigidos para aquele recurso.
• Listas de permissão e negação por IP. Um caminho administrativo restrito aos endereços do escritório devolve 403 para todo o resto, inclusive para quem estiver testando de casa ou de uma rede móvel.
• Regras de firewall de aplicação web. Um WAF bloqueia uma requisição cuja URL, cabeçalhos ou corpo casaram com uma assinatura. Muitas vezes a requisição parece totalmente inocente para você.
• Bloqueio geográfico. O tráfego de alguns países ou regiões é recusado na borda, então o site funciona a partir de um continente e é proibido a partir de outro.
• Proteção contra hotlink. Uma regra que rejeita requisições de imagens ou mídia cujo cabeçalho Referer está ausente ou aponta para outro domínio. Requisições sem referenciador são pegas por acidente com frequência.
• Filtragem de bots e de user agent. A requisição é bloqueada por causa de quem o cliente diz ser, não do que ele pediu. É esse o caso que pega o monitoramento.

O caso do "403 para monitores, 200 para humanos"

Esse é o alarme falso mais comum no monitoramento de disponibilidade, e não é um bug do monitoramento. O site está mesmo devolvendo 403, só que não para navegadores.

O gerenciamento de bots em uma CDN ou WAF pontua cada requisição pelo user agent, pela impressão digital do TLS, pela ordem dos cabeçalhos, pela reputação do IP e pelo fato de resolver ou não um desafio em JavaScript ou interativo. Uma verificação HTTP automatizada é, por definição, um cliente automatizado: ela não roda desafios em JavaScript e se identifica honestamente. Então ela é desafiada ou bloqueada enquanto o seu navegador passa sem problema, e o resultado é um site que alerta como fora do ar enquanto todo humano confirma que ele está no ar.

Dois sinais identificam isso rápido: o 403 chega na hora, e não depois de uma espera, o que descarta sobrecarga, e ele é consistente para o cliente automatizado e nunca reproduzível em um navegador na mesma rede.

Como liberar um serviço de monitoramento

1. Confirme que o bloqueio é por identidade. Repita a requisição como um cliente HTTP comum e depois com uma string de user agent de navegador, e compare:

   curl -sS -o /dev/null -w "%{http_code}\n" https://example.com/
   curl -sS -o /dev/null -w "%{http_code}\n" -A "Mozilla/5.0" https://example.com/

   Se os códigos forem diferentes, é uma regra de user agent que está fazendo isso.
2. Encontre a regra que disparou. Os painéis de WAF e CDN registram as requisições bloqueadas com o id da regra que casou. Isso é mais rápido e mais seguro do que adivinhar qual regra afrouxar.
3. Libere por endereço IP quando puder. Provedores de monitoramento publicam os endereços que os pontos de verificação deles usam. Adicioná-los como regra de exceção é preciso e não enfraquece a proteção para mais ninguém.
4. Ou libere por user agent. Configure a verificação para enviar um user agent distinto e adicione uma regra que o isente. Isso é mais fácil de manter que uma lista de IPs, mas trate como conveniência e não como fronteira de segurança, já que um user agent pode ser copiado por qualquer um.
5. Prefira uma regra de exceção a desligar a proteção. Isente o caminho ou o cliente de monitoramento daquela regra específica e deixe o resto do conjunto em vigor.
6. Teste de novo a partir de várias regiões. Uma regra pode ser aplicada de forma desigual entre as localizações de borda, então confirme a correção de mais de um lugar antes de fechar o chamado.

Corrigir um 403 que não tem a ver com bots

1. Verifique se a URL deveria mesmo ser pública. Metade das investigações de 403 termina com a resposta de que o bloqueio está correto.
2. Confira o dono e as permissões dos arquivos no caminho e em cada diretório pai. O processo do servidor precisa de permissão de execução nos diretórios, não só de leitura no arquivo.
3. Procure um arquivo de índice se a URL for um diretório, ou habilite a listagem de propósito, se for isso que você quer.
4. Leia a configuração do servidor em busca de regras de negação, restrições de IP e checagens de referenciador naquele caminho, e depois a camada de autorização da aplicação.
5. Verifique a borda antes da origem. Faça a requisição direto à origem. Um 403 que some quando você contorna a CDN é uma regra de borda, não um problema da aplicação.

Enxergar o bloqueio de fora da sua própria rede

Um 403 introduzido por uma atualização do WAF ou por uma mudança de permissões não parece uma queda vista de dentro: a sua sessão está autenticada, o seu endereço está liberado, e as páginas que você confere são justamente as que funcionam. Uma verificação HTTP programada exige o código que você espera nas URLs que importam, de fora da sua rede, então uma página recém-proibida gera alerta na hora. Bloqueios geográficos e regras de borda variam por região, então o número de pontos de observação importa: a HostTracker verifica a partir de mais de 300 pontos de verificação em 158 cidades, o que transforma "proibido em alguns países" em uma diferença visível entre localizações. Se a recusa for temporária e ligada ao volume de requisições em vez da identidade, o código costuma ser 429, tratado no guia do 429 Too Many Requests, e a família mais ampla está na visão geral dos 4xx.