DISALLOW_FILE_EDIT: desativar o editor de ficheiros do WordPress

Acrescente uma linha ao wp-config.php: define( 'DISALLOW_FILE_EDIT', true );. Esta linha retira do painel de controlo o Editor de ficheiros do tema e o Editor de ficheiros de plugin. Demora dois minutos e não afeta as atualizações. Elimina ainda o caminho mais curto entre uma palavra-passe de administrador roubada e código a correr no seu servidor.

Este artigo explica porque é que o DISALLOW_FILE_EDIT importa, como o definir em segurança e o que ele não impede. Explica também quando compensa o esforço adicional de usar o DISALLOW_FILE_MODS, que é mais restritivo.

Porque é que o DISALLOW_FILE_EDIT importa: do início de sessão de administrador ao código em execução

O WordPress traz dois editores de código integrados. O Editor de ficheiros do tema fica em Aspeto nos temas clássicos ou em Ferramentas nos temas de blocos. O Editor de ficheiros de plugin fica em Plugins nos temas clássicos ou, também, em Ferramentas nos temas de blocos. Ambos permitem que os administradores (em multisite, os super administradores) alterem ficheiros PHP no navegador e os guardem, e o servidor executa esse código no carregamento de página seguinte.

Na prática, um acesso de administrador equivale a um acesso à shell. Quem tiver uma palavra-passe de administrador obtida por phishing, reutilizada ou descoberta por força bruta pode abrir o functions.php e colar uma backdoor. Pode também acrescentar um redirecionamento oculto para quem chega dos motores de pesquisa ou injetar um skimmer de cartões num modelo de checkout. Nada disto exige FTP nem acesso ao alojamento, basta o início de sessão.

A maioria dos sites em produção nunca precisa de editar código no navegador. Quem desenvolve trabalha num editor de código, num ambiente de teste (staging) ou através de controlo de versões. Editar PHP em direto numa caixa de texto não tem anulação nem revisão, e um único erro de sintaxe pode deixar o site em baixo. Num site de negócio em produção, o editor traz risco e pouco mais.

Proteger o próprio início de sessão é outra tarefa. O nosso guia sobre autenticação de dois fatores para administradores de WordPress trata disso. O DISALLOW_FILE_EDIT limita o que um início de sessão roubado consegue fazer.

Como adicionar o DISALLOW_FILE_EDIT ao wp-config.php

1. Descarregue uma cópia do wp-config.php e guarde-a como cópia de segurança. Em muitos alojamentos, o ficheiro está na raiz do WordPress. Algumas instalações colocam-no um diretório acima.
2. Abra o ficheiro por SFTP ou com o gestor de ficheiros do seu alojamento. Não use um plugin do WordPress para isto.
3. Procure DISALLOW_FILE_EDIT no ficheiro. Se já estiver definido, altere essa linha em vez de acrescentar uma segunda. Definir uma constante duas vezes provoca um aviso do PHP.
4. Acrescente a linha acima do comentário que começa por /* That's all, stop editing!. Tem de vir antes de o wp-settings.php ser carregado.
5. Guarde, envie o ficheiro e volte a carregar o painel de controlo.

/* Disable the Theme and Plugin File Editors in the dashboard */
define( 'DISALLOW_FILE_EDIT', true );

/* That's all, stop editing! Happy publishing. */

Depois, confirme o resultado. As entradas de menu Editor de ficheiros do tema e Editor de ficheiros de plugin devem ter desaparecido. Se abrir diretamente /wp-admin/theme-editor.php, deve agora receber um erro de permissões em vez do editor.

Não é possível voltar a ativar esta constante a partir do painel de controlo, e é precisamente essa a intenção. Quem quiser o editor de volta precisa de acesso aos ficheiros do servidor, não apenas de uma palavra-passe de administrador. A definição aplica-se a toda a instalação e, em multisite, abrange todos os sites da rede. A documentação oficial do wp-config.php enumera-a juntamente com as restantes constantes de configuração.

Se não tiver acesso por SFTP nem a um gestor de ficheiros, o plugin Security Audit & Compliance da secaudit.eu tem um interruptor opcional que desativa os editores de ficheiros do painel de controlo.

Contra o que a desativação do editor de ficheiros não protege

O DISALLOW_FILE_EDIT retira a via mais fácil. Não torna inofensiva uma conta de administrador. Um administrador, ou um atacante que use essa conta, pode na mesma:

• carregar um zip de plugin ou de tema com código malicioso, em Plugins → Adicionar novo ou em Aspeto → Temas
• criar novas contas de administrador, alterar o email do administrador ou repor as palavras-passe de outros utilizadores
• alterar definições, como o URL do site, o registo de utilizadores ou a função por omissão
• exportar dados de utilizadores e de encomendas

Os atacantes com acesso por FTP, SSH, painel do alojamento ou base de dados contornam por completo o WordPress, e nenhuma constante do wp-config.php os trava. A constante também nada faz contra plugins vulneráveis que podem ser explorados sem qualquer início de sessão. Esse é outro problema, com soluções próprias, tratado no nosso guia sobre plugins vulneráveis do WordPress.

Encare o DISALLOW_FILE_EDIT como uma camada. É barata e vale bem a pena, mas não resolve um início de sessão fraco nem um plugin por atualizar.

Plugins de gestão de ficheiros e de snippets: o editor com outro nome

Vários tipos de plugins trazem de volta o mesmo risco, e o DISALLOW_FILE_EDIT não os cobre:

• plugins de gestão de ficheiros, que permitem navegar, editar e carregar ficheiros a partir do painel de controlo
• gestores de snippets de código, que guardam PHP e o executam em cada pedido
• campos de «inserir código no cabeçalho/rodapé» que aceitam scripts ou PHP
• opções de temas ou de page builders com uma caixa de «código personalizado»

Se algum destes estiver ativo, um atacante com acesso de administrador continua a ter um editor de código.

Comece por fazer o inventário. Percorra Plugins → Plugins instalados e as opções do seu tema, e anote tudo o que permita editar ficheiros ou executar código personalizado. Depois, trate cada tipo:

• Gestores de ficheiros: elimine-os assim que terminar a tarefa pontual. Desativar não chega, porque o código permanece no servidor e pode ele próprio ter vulnerabilidades.
• Snippets de que realmente precisa: passe-os para um pequeno plugin próprio ou para um tema filho, e mantenha-o em controlo de versões. As alterações seguem então o seu processo normal de implementação, e não o navegador.
• Gestores de snippets que mantém: verifique que funções podem criar ou editar snippets e restrinja isso ao menor número possível de pessoas.

DISALLOW_FILE_MODS: trinco mais forte, compromissos reais

define( 'DISALLOW_FILE_MODS', true ); vai mais longe. Bloqueia a instalação, a atualização e a eliminação de plugins e temas a partir do painel de controlo. Desliga também as atualizações automáticas em segundo plano do WordPress. Fecha assim a via do carregamento de zips que o DISALLOW_FILE_EDIT deixa aberta.

O custo é que nada se atualiza sozinho. Se ninguém executar as atualizações de outra forma, o site vai ficando para trás nas correções de segurança. Os avisos habituais de atualização desaparecem também do painel de controlo. Só a Saúde do site indica que as atualizações em segundo plano estão desligadas, pelo que a falha passa facilmente despercebida.

Defina uma via de atualização antes de ativar o DISALLOW_FILE_MODS

Escolha uma destas abordagens e torne-a rotina:

• WP-CLI no servidor. Execute as atualizações a partir da linha de comandos, à mão ou como tarefa agendada:

wp core update
wp plugin update --all
wp theme update --all

• Implementação por Git ou Composer. As versões dos plugins e dos temas ficam definidas no seu repositório, e uma pipeline compila e implementa o site. As atualizações passam a ser commits que pode rever e reverter.
• Ferramentas de atualização do alojamento gerido. Alguns fornecedores executam as atualizações por si, muitas vezes com uma cópia de segurança ou verificação visual prévia. Esclareça exatamente o que está coberto e se os plugins premium estão incluídos.

Teste o método escolhido numa cópia de staging com o DISALLOW_FILE_MODS já ativo. A configuração do seu servidor determina o que ali funciona, por isso confirme-o antes de mexer na produção.

Agende as atualizações com uma tarefa cron ou um gatilho da pipeline e verifique que a tarefa corre mesmo. Uma tarefa que falha em silêncio não é melhor do que não ter tarefa nenhuma. Mantenha um registo do que foi atualizado e quando. Esse registo é uma boa prova de «medidas técnicas e organizativas adequadas» nos termos do artigo 32.º do RGPD.

A rapidez conta. A Patchstack, um fornecedor de segurança, indica no seu relatório State of WordPress Security in 2026 que a mediana ponderada do tempo até à exploração em massa foi de 5 horas nas vulnerabilidades mais exploradas. Uma ronda mensal de atualizações manuais não acompanha esse ritmo.

Confirme que o bloqueio continua em vigor

As constantes perdem-se com facilidade em migrações, mudanças de alojamento e depurações «temporárias». Verifique-as de vez em quando:

grep -n DISALLOW_FILE wp-config.php
wp config get DISALLOW_FILE_EDIT

O primeiro comando mostra todas as linhas correspondentes com o respetivo número. O segundo mostra o valor que o WP-CLI lê da configuração. Execute ambos de novo após cada mudança para um novo servidor ou alojamento. Fique também atento a alterações inesperadas nos ficheiros PHP do seu tema e dos plugins. Com o bloqueio em vigor, uma alteração dessas significa que alguém entrou por outra via.

Se descobrir que o editor já foi usado contra si, deixou de ser reforço de segurança e passou a ser resposta a incidentes. Leia os nossos guias sobre como encontrar web shells e remoção de malware no WordPress antes de alterar mais alguma coisa.

O plugin de auditoria da secaudit.eu verifica as suas definições de reforço e de configuração, incluindo o editor de ficheiros. Acompanha também a integridade dos ficheiros em relação a uma linha de base, pelo que as alterações aos ficheiros do tema e dos plugins aparecem no relatório → secaudit.eu

FAQ

O DISALLOW_FILE_EDIT pode estragar o meu site ou as atualizações?

Não. Apenas retira os dois editores do painel de controlo. As atualizações de plugins, temas e do núcleo, incluindo as automáticas, continuam a funcionar. Só o DISALLOW_FILE_MODS altera o modo como as atualizações funcionam.

Posso reativar o editor temporariamente?

Pode. Defina a constante como false ou comente a linha e restaure-a depois. É preferível editar o ficheiro por SFTP ou em staging, para que o editor nunca precise de voltar.

O WordPress tem esta opção no painel de controlo?

Não. O núcleo não tem nenhuma opção no painel de controlo para isto; é uma constante que se define no wp-config.php. Se não puder editar esse ficheiro, use um plugin que ofereça um interruptor para desativar os editores de ficheiros.