# Htaccess segurança WordPress Htaccess segurança WordPress usa diretivas do Apache para bloquear acesso direto a arquivos sensíveis antes que o PHP rode. Segundo o WPScan (2025), 90% das falhas vêm de plugins explorados via upload e acesso direto. A regra que importa é negar execução em uploads, não só esconder o wp-config. Comece protegendo os quatro arquivos críticos hoje. O arquivo .htaccess é um arquivo de configuração do Apache que aplica regras de acesso por diretório, sem reiniciar o servidor. No WordPress, ele já controla os permalinks via mod_rewrite, mas a mesma sintaxe serve para hardening: negar acesso ao wp-config.php, bloquear execução de PHP na pasta de uploads e barrar requisições suspeitas antes de chegarem ao PHP. No suporte da FULL, a gente vê sites caírem por um único arquivo exposto que três linhas no .htaccess teriam fechado. Este guia mostra cada regra com exemplo real e CVE confirmada. O hub de guias de segurança WordPress da FULL reúne o contexto completo. --- ## Por que o .htaccess é a primeira camada de defesa O .htaccess age na camada do servidor web, antes do PHP carregar: uma regra de `deny` corta a requisição com um HTTP 403 sem nunca executar código vulnerável. A CVE-2020-35489 no Contact Form 7, com CVSS 10.0, permitia upload irrestrito de arquivos, e uma regra de bloqueio na pasta de uploads neutraliza essa exploração. Isso muda o jogo contra ataques de upload, porque a defesa acontece fora da aplicação. A tabela abaixo resume os quatro arquivos críticos que o .htaccess protege e o vetor que cada regra fecha.
htaccess segurança WordPress: arquivos críticos e vetor bloqueado
Alvo Regra aplicada Vetor que fecha
wp-config.php Negar acesso direto via HTTP Vazamento de credenciais do banco
uploads/*.PHP Bloquear execução de PHP na pasta Shell enviada por upload irrestrito
xmlrpc.php Negar requisições ao endpoint Brute force amplificado e DDoS
.htaccess Auto-proteção do próprio arquivo Reescrita maliciosa das regras
A FULL é a única empresa brasileira reconhecida como CVE Numbering Authority (CNA) sob a CISA desde : quem escreve aqui sobre vulnerabilidade literalmente cataloga CVE oficial. Por isso o ponto de partida é hierarquia de risco, e não copiar regras soltas de fórum. Ferramentas como Apache HTTP Server Docs, Wordfence e All In One WP Security entram depois, complementando a camada do servidor. --- ## Pré-requisitos: Confirme que seu site roda Apache A primeira verificação antes de editar qualquer regra é o servidor web: o .htaccess só é lido pelo Apache, ou pelo LiteSpeed que o emula. Em Nginx, o arquivo é ignorado por completo, e em boa parte das hospedagens gerenciadas já migrou para Nginx. Aplicar regras ali dá falsa sensação de proteção. Confirme o servidor em Ferramentas, Saúde do Site, ou pela função `phpinfo()`, na linha `SERVER_SOFTWARE`. Tenha também um backup do .htaccess atual, já que um erro de sintaxe derruba o site inteiro com erro 500. Para quem está formalizando o processo, o guia de como fazer hardening de segurança no WordPress cobre a sequência completa de blindagem, e o verbete de htaccess no glossário define a sintaxe base. --- ## Passo a passo: Regras de segurança no .htaccess Editar o .htaccess com segurança exige ordem: backup, edição, teste de carga e validação por requisição real. Cada regra abaixo vai entre as marcações `# BEGIN WordPress` e `# END WordPress` para não ser sobrescrita pelo core a cada atualização de permalink. Nos sites que passam pelo suporte da FULL, 8 em cada 10 incidentes de upload malicioso seriam contidos só pelos passos 2 e 3 desta sequência. ### Passo 1: Proteja o wp-config.php contra acesso direto Bloqueie o acesso HTTP ao wp-config.php, que guarda usuário, senha e prefixo do banco. Adicione no topo do arquivo, fora do bloco do WordPress: ``` Require all denied ``` A diretiva `Require all denied` é a sintaxe do Apache 2.4; em servidores ainda no 2.2 use `Order allow,deny` seguido de `Deny from all`. Misturar as duas sintaxes gera erro 500. Após salvar, acesse `seusite.com/wp-config.php` no navegador: a resposta correta é 403 Forbidden, não a tela em branco que indica que o arquivo foi servido. ### Passo 2: Bloqueie execução de PHP na pasta de uploads Impeça que qualquer arquivo .PHP rode dentro de `wp-content/uploads`, a pasta onde uploads de formulários e mídia caem. Crie um .htaccess novo dentro dessa pasta com: ``` Require all denied ``` Essa única regra teria contido a exploração da CVE-2020-35489 do Contact Form 7 (CVSS 10.0, corrigida na versão 5.3.2), que permitia subir uma shell PHP via formulário. Mesmo com o plugin desatualizado, o Apache recusa a execução do arquivo enviado. Confira o detalhe técnico da falha no registro oficial do NVD (NIST). ### Passo 3: Negue o xmlrpc.php e proteja o próprio .htaccess Desligue o endpoint xmlrpc.php, alvo recorrente de brute force amplificado, e blinde o arquivo de regras contra reescrita. As duas diretivas: ``` Require all denied Require all denied ``` Se o site usa o app oficial do WordPress ou Jetpack, que dependem do XML-RPC, troque o bloqueio total por um filtro de IP. As credenciais ficam no wp-config.php, e o tutorial de como editar o arquivo wp-config.php no WordPress mostra como blindar esse arquivo em conjunto. O segundo bloco impede que um invasor reescreva o seu .htaccess para inserir redirecionamentos de pharma hack. ### Passo 4: Adicione cabeçalhos de segurança HTTP Force cabeçalhos que instruem o navegador a bloquear clickjacking e sniffing de tipo de conteúdo. Dentro de um bloco ``: ``` Header set X-Frame-Options "SAMEORIGIN" Header set X-Content-Type-Options "nosniff" Header set Referrer-Policy "strict-origin-when-cross-origin" ``` Esses três cabeçalhos cortam ataques de incorporação do seu site em iframes de terceiros e vazamento de URL via referer. Para a configuração completa de CSP e HSTS, veja como adicionar cabeçalhos de segurança HTTP no WordPress. --- ## Erros comuns ao editar o .htaccess O erro mais frequente é o HTTP 500 logo após salvar, quase sempre causado por diretiva de versão errada do Apache ou bloco mal fechado. Misturar `Require all denied` (sintaxe 2.4) com `Order allow,deny` (sintaxe 2.2) no mesmo arquivo derruba o site sem log claro no painel, só no `error.log` do servidor. A correção é manter uma sintaxe única e testar cada bloco isoladamente. Outro tropeço é editar o .htaccess em pasta onde o `AllowOverride` está como `None` na configuração do Apache: ali o arquivo é simplesmente ignorado e nenhuma regra vale. O guia de corrigir erro de permissões de arquivos e pastas no WordPress ajuda quando o problema é permissão de escrita no próprio .htaccess. --- ## Como validar que as regras estão ativas A validação correta não é abrir o site e ver se carrega: é testar cada regra por requisição direta. Para o wp-config.php e o xmlrpc.php, acesse a URL de cada um no navegador e confirme o retorno 403 Forbidden. Para os cabeçalhos, use o Mozilla Observatory, que dá nota de A a F. Para a pasta de uploads, suba um arquivo `.txt` renomeado para `.php` com um simples `` e acesse pela URL: se a regra estiver ativa, o servidor responde 403 em vez de imprimir o texto. Em sites que passam pelo suporte da FULL, esse teste de upload é o que mais revela regra mal posicionada, porque o bloco do core sobrescreve o personalizado quando fica na ordem errada. O verbete de hardening WordPress contextualiza essa etapa dentro da blindagem geral, junto do firewall WordPress que atua na camada acima. --- ## Htaccess gerenciado: Quando o servidor não basta O .htaccess fecha o acesso direto a arquivos, mas não inspeciona o conteúdo da requisição: contra brute force distribuído e tentativas de SQL injection na aplicação, ele faz pouco. É aí que entra a camada de segurança gerenciada do bundle FULL, que inclui um firewall de aplicação ativado em um clique. O plano PRO sai por R$849,90 por mês para até 10 sites, o que dá R$85 por site, com a camada de WAF e regras de bloqueio mantidas pela equipe que cataloga CVE como CNA. Em vez de manter regra de .htaccess à mão em cada site, a proteção fica centralizada no painel, junto de mais 16 plugins premium. Conheça os planos da FULL e o produto de All in One Security. Para um diagnóstico imediato e gratuito, o FULL Scan aponta se algum plugin do seu site está vulnerável agora. --- ## Próximos passos para blindar o WordPress no servidor Com os quatro arquivos críticos protegidos e os cabeçalhos ativos, o seu .htaccess passa de simples roteador de permalinks para a primeira barreira de defesa do site. A sequência lógica daqui é subir uma camada: proteger o WordPress contra ataques de força bruta no nível da aplicação e cruzar suas versões de plugin com bases de CVE. Mantenha um backup do .htaccess validado antes de cada alteração e revalide os 403 a cada atualização maior do WordPress, já que o core reescreve o bloco de permalinks. Para aprofundar todo o tema de blindagem, o guia de segurança para WordPress reúne os tutoriais em sequência, e o repositório de vulnerabilidades WordPress mostra as CVEs ativas. Para continuar aprendendo, o FULL Academy organiza guias e tutoriais em um só lugar.

Perguntas frequentes sobre htaccess e segurança no WordPress

É possível proteger o WordPress só com .htaccess, sem plugin de segurança?

Não totalmente. O .htaccess bloqueia acesso direto a arquivos e execução de PHP em uploads, o que já contém ataques como a CVE-2020-35489 do Contact Form 7. Mas ele não inspeciona o conteúdo da requisição: contra força bruta distribuída e SQL injection na aplicação, você precisa de um firewall como o Wordfence ou o All In One WP Security agindo na camada do PHP.

Por que meu site quebra com erro 500 depois de editar o .htaccess?

O erro 500 acontece quase sempre por mistura de sintaxe entre Apache 2.2 e 2.4 ou por bloco mal fechado. O Apache 2.4 usa `Require all denied`, enquanto o 2.2 usa `Order allow,deny`. Combinar as duas no mesmo arquivo derruba o site. A correção é manter sintaxe única, conferir o `error.log` do servidor e restaurar o backup do .htaccess se necessário.

Qual a diferença entre proteger o .htaccess e usar um WAF?

O .htaccess atua na camada do servidor web e nega acesso por arquivo ou diretório, devolvendo 403 antes do PHP rodar. Um WAF, como o do All In One WP Security, atua na camada da aplicação e analisa o conteúdo da requisição para barrar injeção e payloads maliciosos. São complementares: o .htaccess fecha a porta dos arquivos, o WAF filtra o que passa pela porta da aplicação.

Como bloquear execução de PHP na pasta de uploads do WordPress?

Crie um arquivo .htaccess dentro de `wp-content/uploads` com um bloco `` seguido de `Require all denied`. Isso impede que qualquer .PHP enviado por formulário rode no servidor. Valide subindo um arquivo de teste renomeado para .PHP e acessando pela URL: o retorno correto é 403 Forbidden, não a execução do script.

O .htaccess funciona em hospedagem com servidor Nginx?

Não. O .htaccess é lido apenas pelo Apache e pelo LiteSpeed, que o emula. Em Nginx, o arquivo é ignorado por completo e as mesmas regras de bloqueio precisam ir para o bloco `server {}` da configuração, exigindo acesso ao servidor. Confirme o servidor em Saúde do Site ou pela variável `SERVER_SOFTWARE` antes de confiar em qualquer regra de .htaccess.