Erro 403 Forbidden (HTTP ERROR 403): O Que É e Como Resolver

O erro 403 Forbidden — que muitos navegadores exibem como “HTTP ERROR 403” ou “403 Forbidden – Acesso negado” — significa que o servidor entendeu o seu pedido, mas se recusa a atender: o acesso àquela página está proibido.

O que é o erro 403 Forbidden

O 403 é um código de status HTTP da família 4xx (erros do lado do cliente). Ele indica que o servidor recebeu e compreendeu a requisição, mas se recusa a autorizá-la. Não confunda com o erro 401 (Unauthorized): no 401, falta autenticação (você não se logou); no 403, você está autenticado mas não tem permissão.

Em termos simples: a porta existe, mas você não tem a chave.

Tabela comparativa de códigos HTTP:

Variações e mensagens do erro 403

Um dos motivos que deixam o erro 403 confuso é que ele quase nunca aparece com o mesmo texto. A mensagem muda conforme três fatores: o servidor web que hospeda o site (Apache, Nginx ou IIS), o navegador que você está usando e, principalmente, a forma como o dono do site personalizou a página de erro. Apesar da aparência diferente, todas comunicam a mesma coisa: o servidor entendeu o pedido, mas se recusa a atendê-lo.

Saber “ler” a variação ajuda a diagnosticar a causa mais rápido — em muitos casos, o próprio texto já entrega onde está o problema. Veja as formas mais comuns e o que cada uma indica.

Mensagens genéricas (sem pista da causa)

São as mais frequentes e, infelizmente, as menos informativas. Indicam que o acesso foi negado, mas não dizem o porquê:

Mensagens que revelam a causa

Subcódigos do IIS (servidores Windows)

Se o site roda em Microsoft IIS (hospedagem Windows), o 403 vem com um número após o ponto, e cada subcódigo aponta uma causa específica. Esse é o caso em que a mensagem mais ajuda no diagnóstico:

Como a mensagem aparece em cada navegador

Vale lembrar que o navegador também influencia o que você vê. O Chrome costuma mostrar uma página simples com “HTTP ERROR 403”; o Firefox exibe algo como “Acesso negado”; e o Safari apresenta a mensagem bruta do servidor. Quando o dono do site cria uma página de erro personalizada, ela pode trazer o logo da empresa, um texto bem-humorado ou instruções próprias — mas o código por trás continua sendo 403.

Principais causas do erro 403

Fluxograma de diagnóstico

A lógica é simples: descubra primeiro de qual lado está o problema.

• Apareceu erro 403 → o site falha em outro dispositivo?
• Não (só no meu PC) → Problema do CLIENTE → limpe cache, cookies, VPN → resolvido.
• Sim (para todos) → Problema do SERVIDOR → verifique .htaccess, permissões e plugins.
  • Resetou .htaccess e resolveu? → Sim: resolvido. → Não: ajuste permissões, desative plugins; se persistir, fale com o suporte.

Como resolver — lado do visitante

Recarregue e confira o endereço: Ctrl + F5 (ou Cmd + Shift + R no Mac).

Limpe cache e cookies: dados antigos guardados pelo navegador podem manter uma sessão inválida e disparar o 403. No Chrome, vá em Configurações → Privacidade e segurança → Limpar dados de navegação, marque “Cookies e outros dados do site” e “Imagens e arquivos armazenados em cache“, escolha o período “Todo o período” e confirme.

Depois, recarregue a página. Se você usa outro navegador (Firefox, Edge, Safari) ou quer o passo a passo detalhado com telas, veja nosso guia como limpar o cache do navegador — ele mostra o processo completo em cada navegador e explica a diferença entre cache, cookies e histórico.

Desative VPN ou proxy: servidores podem bloquear faixas de IP.

Teste em outra rede: o 4G do celular ajuda a isolar se o bloqueio é do seu IP.

Como resolver — lado do dono do site

Faça backup antes de tudo.

Depois: desative os plugins (renomeie wp-content/plugins), regenere o .htaccess em Configurações → Links Permanentes, e ajuste permissões.

Permissões corretas de arquivos e pastas

Comandos via SSH para corrigir em massa:

find /caminho/do/site -type d -exec chmod 755 {} \;
find /caminho/do/site -type f -exec chmod 644 {} \;

Corrigindo o .htaccess

Procure por regras restritivas (Deny from all) e troque por Allow from all.

Se não achar, renomeie para .htaccess.bak para desativá-lo e teste.

Veja os guias da HomeHost sobre .htaccess do WordPress e o guia completo do .htaccess.

Como encontrar a causa nos logs do servidor

Os logs registram exatamente qual arquivo foi bloqueado e por quê — é o caminho mais direto quando as tentativas anteriores não resolveram.

No cPanel: vá em Métricas → Erros. A tela mostra as últimas entradas do log de erro do seu site, já filtradas para a sua conta.

Em servidor próprio (VPS ou dedicado): os logs ficam em /var/log/apache2/error.log (Debian/Ubuntu), /var/log/httpd/error_log (CentOS/AlmaLinux) ou /var/log/nginx/error.log no Nginx. Para filtrar só as ocorrências de 403:

grep " 403 " /var/log/nginx/access.log | tail -20
grep "Permission denied" /var/log/nginx/error.log | tail -20

O que procurar nas entradas:

• Permission denied → permissões de arquivo ou pasta incorretas. O log informa o caminho exato do arquivo bloqueado.
• directory index of ... is forbidden → falta arquivo índice na pasta, e a listagem de diretório está desativada.
• access forbidden by rule → uma regra deny na configuração do servidor está bloqueando.
• ModSecurity: Access denied → o firewall de aplicação bloqueou a requisição. O log traz o ID da regra que disparou — anote esse número para passar ao suporte.

Se o log apontar o arquivo e o motivo, você poupa todas as tentativas por eliminação.

ModSecurity e firewall de aplicação (WAF)

Em hospedagem compartilhada, um firewall de aplicação como o ModSecurity roda no servidor e inspeciona cada requisição. Quando o conteúdo enviado se parece com um ataque, ele bloqueia — e devolve 403.

O caso mais comum é o dono do site sendo bloqueado ao salvar um post que contém código (exemplos de SQL, tags HTML, trechos de PHP). O WAF interpreta como tentativa de injeção e barra o salvamento.

Como identificar: o 403 acontece só em uma ação específica — publicar um post, enviar um formulário, acessar uma URL com parâmetros — e não no site inteiro. Os logs do servidor registram a regra que disparou.

A solução é o suporte da hospedagem ajustar ou liberar aquela regra específica. Desativar o ModSecurity inteiro não é recomendável: ele bloqueia ataques reais o tempo todo.

Erro 403 no Nginx

O Nginx não usa .htaccess — toda a configuração fica nos arquivos do servidor, normalmente em /etc/nginx/sites-available/ . Isso muda o diagnóstico: não adianta procurar ou renomear .htaccess.

Verifique, nesta ordem:

A diretiva try_files. É a causa mais frequente de 403 no Nginx e a mais fácil de passar despercebida. Ela define o que o servidor faz quando a URL não corresponde a um arquivo. Se estiver ausente ou incompleta, o Nginx tenta listar o diretório — e devolve 403, porque a listagem é desativada por padrão. A configuração correta para WordPress é:

location / {
    try_files $uri $uri/ /index.php?$args;
}

A diretiva index. Confirme que os arquivos índice estão declarados:

index index.php index.html index.htm;

Regras deny. Procure por blocos com deny all ou deny seguido de um IP. Eles podem ter sido adicionados por uma ferramenta de segurança ou herdados de uma configuração antiga.

Bloqueios por user agent. Regras que barram determinados navegadores ou bots às vezes pegam tráfego legítimo junto.

Permissões e o usuário do Nginx. O processo do Nginx (normalmente www-data ou nginx) precisa ter permissão de leitura nos arquivos e de execução nas pastas do caminho inteiro — inclusive nas pastas acima da raiz do site.

Depois de qualquer alteração, valide e recarregue:

sudo nginx -t
sudo systemctl reload nginx

O nginx -t aponta o arquivo e a linha de qualquer erro de sintaxe antes de aplicar — sempre rode antes do reload.

Se o seu servidor roda Nginx, nosso guia dedicado ao erro 403 no Nginx cobre o diagnóstico completo — incluindo o SELinux, que é a causa mais difícil de identificar porque não aparece no log do Nginx.

Erro 403 causado por CDN ou firewall externo

Se o seu site passa por uma CDN como o Cloudflare, o 403 pode ter sido gerado por ela, e não pelo seu servidor. Nesse caso, nenhuma alteração de permissão ou .htaccess resolve, porque a requisição nunca chegou à sua origem.

As causas mais comuns nessa camada:

• Regras de WAF do Cloudflare bloqueando o tráfego por país, IP ou padrão de requisição
• Proteção contra hotlink barrando imagens e arquivos acessados a partir de outro domínio
• Regras de firewall criadas manualmente e esquecidas
• Modo “Under Attack” ativado, que aplica verificações mais rígidas a todos os visitantes

Como identificar: pause temporariamente a CDN — no Cloudflare, use Pause Cloudflare on Site na tela Overview, ou deixe o registro de DNS com a nuvem cinza. Se o erro desaparecer, a causa está na CDN. Se continuar, o problema é do seu servidor.

A página de erro também dá pistas: mensagens com marca do Cloudflare, ou que citam cloudflare-nginx, indicam que a resposta veio da borda da CDN. O mesmo raciocínio de identificar quem gerou o erro se aplica a outros códigos — nosso guia sobre erro 500 no Cloudflare detalha o método.

Veja também

O erro 403 pertence aos códigos de status HTTP da classe 4XX (erros do cliente). Veja também: 400 Requisição Inválida, 401 Não Autorizado e 404 Não Encontrado.

Se o seu servidor é Nginx, veja também o erro 403 no Nginx.