Erro 403 Forbidden: o que significa e como corrigir

O que este erro significa e como reconhecê-lo

• Um navegador exibe 403 Forbidden, Access Denied ou uma página de negação personalizada.
• Um cliente de API recebe HTTP 403 mesmo tendo fornecido credenciais.
• O DNS e o TLS podem funcionar normalmente, pois a solicitação chegou a um servidor HTTP ou intermediário.
• Apenas um caminho, arquivo, conta, endereço IP, método HTTP ou rede pode ser afetado.
• Uma resposta de CDN ou WAF pode incluir headers específicos do provedor, um identificador de solicitação ou uma página de desafio ou negação de segurança.
• O erro pode começar após um deploy, uma alteração de permissões, uma atualização de regras de reescrita, uma mudança no firewall ou uma atualização da política do WAF.

Causas principais, por probabilidade

As causas prováveis, ordenadas das mais comuns às menos comuns, incluem:

1. Autorização ausente: O recurso exige um usuário autenticado, uma função específica, propriedade, assinatura ou escopo de token de API.
2. Filtragem de CDN ou WAF: Uma política de segurança pode bloquear o IP do cliente, o padrão da solicitação, o país, o user agent, a taxa de solicitações ou a URL.
3. Regras de acesso do servidor web: A configuração do Apache ou Nginx pode negar um caminho por meio de regras allow/deny, de localização, reescrita, diretório ou arquivo de índice.
4. Problemas de acesso a arquivos ou diretórios: Propriedade ou permissões incorretas podem impedir que o processo do servidor web percorra diretórios ou leia um recurso.
5. Lógica de autorização da aplicação: A aplicação pode retornar deliberadamente 403 para um usuário, objeto, operação ou estado de conta.
6. Restrições de rede ou hotlink: Listas de permissões de IP, verificações de referer ou outras políticas de acesso podem rejeitar uma solicitação válida.

Um 403 pode ser intencional. Confirme que o recurso deveria estar disponível para o usuário ou cliente afetado antes de alterar a configuração.

Como corrigir

Se você é um visitante

1. Verifique o endereço exato. Confira o hostname, caminho, ortografia, query string e uso de maiúsculas e minúsculas. Remova alterações acidentais da URL e tente novamente a página desejada.
2. Faça login se necessário. Se o recurso pertence a uma conta ou assinatura, autentique-se e confirme que a conta tem a função ou o plano necessários.
3. Faça um teste de rede apropriado. Se o site puder restringir VPNs, proxies, redes corporativas ou endereços IP, tente novamente a partir de uma rede aprovada. Não tente contornar uma política de acesso sem permissão.
4. Evite novas tentativas automatizadas repetidas. Solicitações repetidas podem acionar regras de taxa ou segurança e dificultar o diagnóstico.
5. Entre em contato com o proprietário do site quando o acesso deveria ser público. Inclua a URL exata, o horário aproximado, a conta ou rede afetada e qualquer identificador de solicitação exibido na página de erro. Não envie senhas, cookies de sessão ou segredos de API.

Se você administra o site ou a API

1. Reproduza e registre a solicitação. Anote a URL exata, o método HTTP, o fuso horário, o IP do cliente quando apropriado, o contexto de autenticação, o status, os headers da resposta e qualquer request ID ou Ray ID. Remova os segredos antes de compartilhar os logs.
2. Identifique a camada que respondeu. Determine se a resposta veio da aplicação, do servidor web, do reverse proxy, da CDN ou do WAF. Páginas de negação personalizadas e headers específicos do provedor podem fornecer pistas, mas confirme a origem nos logs.
3. Verifique a autenticação e a autorização. Confirme se a conta, função, token de API, escopo OAuth, propriedade do recurso e operação solicitada são permitidos. Uma credencial válida comprova a autenticação, não a autorização para todos os recursos.
4. Inspecione os eventos da CDN e do WAF. Relacione a solicitação ao evento e à regra de segurança correspondentes. Se a solicitação for legítima, prefira uma exceção restrita e autenticada; não desative a proteção globalmente.
5. Revise as regras do servidor web. Examine as configurações de virtual host, localização, diretório, allow/deny, reescrita e arquivo de índice do Apache ou Nginx. Compare-as com a última configuração conhecida como funcional.
6. Verifique a propriedade e as permissões. Confirme que o processo do servidor web pode percorrer os diretórios necessários e ler o arquivo de destino. Preserve o princípio do menor privilégio e não altere os arquivos para permissões graváveis globalmente.
7. Revise o comportamento da aplicação. Verifique a autorização por rota, a propriedade do objeto, o middleware de controle de acesso e alterações recentes no código ou na configuração. Corrija um 403 deliberado da aplicação na política de autorização, em vez de enfraquecer o servidor web.
8. Teste novamente de forma restrita. Após uma correção autorizada e mínima, teste a URL e o método exatos a partir do contexto afetado. Confirme que caminhos privados não relacionados continuam protegidos e monitore os logs em busca de novas negações.

Prevenção e como verificar a correção

• Documente quais caminhos são públicos, autenticados, restritos por função ou intencionalmente negados.
• Aplique funções de aplicação e permissões de arquivos com o menor privilégio; evite arquivos e diretórios graváveis globalmente.
• Restrinja as regras de CDN, WAF, IP, hotlink e servidor ao menor caminho ou público necessário.
• Teste alterações nas regras de segurança e do servidor web em um ambiente controlado antes de uma implantação ampla.
• Monitore as taxas de 401 e 403 por rota e correlacione picos com releases, alterações de configuração e eventos de segurança.
• Mantenha configurações versionadas e um caminho de rollback testado para alterações de controle de acesso.
• Registre o proprietário esperado de cada camada de negação para que os incidentes sejam encaminhados rapidamente.

Perguntas frequentes