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.

A FULL é a única empresa brasileira reconhecida como CVE Numbering Authority (CNA) sob a CISA desde maio de 2022: 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 2026 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:

<Files wp-config.php>
  Require all denied
</Files>

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:

<FilesMatch ".(php|php5|phtml|phar)$">
  Require all denied
</FilesMatch>

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:

<Files xmlrpc.php>
  Require all denied
</Files>
<Files ~ "^.ht">
  Require all denied
</Files>

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 :

<IfModule mod_headers.c>
  Header set X-Frame-Options "SAMEORIGIN"
  Header set X-Content-Type-Options "nosniff"
  Header set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>

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