Ao utilizar o TinyMCE para editar e salvar conteúdo HTML, uma situação específica pode causar o erro 403 Forbidden: o envio de elementos contendo o atributo style="". Neste caso, o problema não estava no TinyMCE nem diretamente no código PHP da aplicação, mas no ModSecurity do servidor, que estava bloqueando a requisição.
O problema: erro 403 ao usar style no TinyMCE
O problema ocorria durante o uso do TinyMCE quando o conteúdo enviado pelo editor possuía HTML com o atributo style.
Por exemplo, ao salvar um conteúdo semelhante a:
<p style="text-align: center;">Texto centralizado</p> |
a requisição era bloqueada pelo servidor e retornava:
403 Forbidden |
Sem o atributo style="", a operação funcionava normalmente.
Esse comportamento inicialmente pode levar à suspeita de algum problema no TinyMCE, no formulário, no processamento do HTML ou no código PHP responsável por receber o conteúdo. Entretanto, neste caso, o bloqueio estava ocorrendo no servidor.
Por que o ModSecurity pode causar erro 403 no TinyMCE?
O ModSecurity funciona como uma camada de segurança para analisar as requisições HTTP recebidas pelo servidor. Dependendo das regras configuradas pela hospedagem, determinados conteúdos enviados através de formulários podem ser classificados como potencialmente perigosos.
Um editor HTML como o TinyMCE envia tags, atributos e outros elementos HTML como parte dos dados do formulário. Neste caso específico, a presença do atributo style="" fazia com que uma regra do ModSecurity fosse acionada.
Como consequência, a requisição era interrompida e o navegador recebia o erro HTTP 403.
O comportamento observado era, portanto:
- conteúdo enviado pelo TinyMCE sem
style="": funcionava; - conteúdo enviado pelo TinyMCE contendo
style="": retornava erro 403; - ModSecurity desativado: o mesmo conteúdo era salvo normalmente.
Esse conjunto de testes indicou que o bloqueio estava relacionado às regras de segurança do servidor e não ao funcionamento do editor TinyMCE.
Como diagnosticar o erro 403 causado pelo ModSecurity
Uma forma simples de investigar esse tipo de problema é reduzir o HTML enviado pelo TinyMCE até encontrar o elemento que provoca o bloqueio.
Por exemplo, teste inicialmente:
<p>Teste de conteúdo</p> |
Se funcionar, adicione o atributo style:
<p style="color: red;">Teste de conteúdo</p> |
Se o primeiro conteúdo for aceito e o segundo retornar 403 Forbidden, existe uma indicação de que alguma regra de segurança está analisando e bloqueando o conteúdo da requisição.
No caso analisado, a confirmação ocorreu ao desativar temporariamente o ModSecurity: o conteúdo contendo style="" passou a ser aceito normalmente.
Como corrigir o erro 403 do TinyMCE causado pelo ModSecurity
No ambiente testado, uma das soluções que funcionou foi criar ou editar o arquivo .htaccess localizado na raiz do sistema e adicionar a seguinte configuração:
<IfModule mod_security.c> SecRuleEngine Off </IfModule> |
A diretiva SecRuleEngine Off desativa o processamento das regras do ModSecurity no contexto em que essa configuração for permitida pelo servidor.
Após colocar o .htaccess na raiz do sistema, o conteúdo enviado pelo TinyMCE contendo atributos style="" deixou de gerar o erro 403.
Desativando o ModSecurity pelo cPanel
Outra forma utilizada para confirmar o problema foi desativar o ModSecurity diretamente através do cPanel.
Quando a hospedagem oferece esse recurso, o teste pode ser realizado da seguinte forma:
- Acesse o cPanel da hospedagem.
- Localize a opção relacionada ao ModSecurity.
- Localize o domínio onde o sistema está instalado.
- Desative temporariamente o ModSecurity.
- Retorne ao sistema.
- Envie novamente pelo TinyMCE um conteúdo contendo
style="".
Neste caso, desativar o ModSecurity pelo cPanel também eliminou o erro 403.
Esse teste foi importante porque confirmou que o TinyMCE conseguia enviar normalmente o mesmo HTML quando as regras do ModSecurity não estavam interferindo na requisição.
Por que as duas soluções funcionaram?
Tanto a alteração realizada através do arquivo .htaccess quanto a desativação pelo cPanel interferem no funcionamento do ModSecurity.
No arquivo .htaccess, foi utilizada a diretiva:
SecRuleEngine Off |
Com o processamento das regras desativado, o conteúdo HTML contendo style="" deixou de ser bloqueado.
Já pelo cPanel, o ModSecurity foi desativado utilizando o mecanismo disponibilizado pela própria hospedagem para o domínio.
O fato de as duas alterações eliminarem o mesmo erro 403 confirmou que o bloqueio estava relacionado ao ModSecurity.
O TinyMCE precisa ser alterado?
Neste cenário, não foi necessário remover o suporte ao atributo style do TinyMCE apenas para contornar o erro.
O editor estava produzindo e enviando o HTML esperado. O erro 403 acontecia posteriormente, quando a requisição chegava ao servidor e era analisada pelo ModSecurity.
Isso é importante durante o diagnóstico porque tentar resolver o problema apenas modificando as configurações do TinyMCE pode esconder a causa real.
Se a aplicação realmente precisa armazenar formatação inline, remover todos os atributos style pode não ser uma solução adequada.
Desativar o ModSecurity permanentemente é recomendado?
Não é recomendado utilizar a desativação completa do ModSecurity como primeira opção de correção definitiva em produção.
A desativação é extremamente útil para confirmar o diagnóstico: se o ModSecurity está ativo e ocorre erro 403, mas ao desativá-lo exatamente a mesma requisição funciona, fica muito mais fácil localizar a origem do problema.
Depois dessa confirmação, o ideal é consultar os logs do ModSecurity para descobrir qual regra foi acionada pelo conteúdo enviado pelo TinyMCE.
Com o identificador da regra responsável pelo falso positivo, o administrador do servidor ou o suporte da hospedagem poderá avaliar uma exceção específica para a aplicação, em vez de desativar toda a camada de proteção.
Alternativa para diagnóstico com DetectionOnly
Em servidores nos quais existe controle sobre a configuração do ModSecurity, outra possibilidade para diagnóstico é utilizar:
SecRuleEngine DetectionOnly |
Nesse modo, as regras continuam sendo processadas para fins de detecção, mas não executam as ações disruptivas de bloqueio. Isso pode facilitar a identificação da regra relacionada ao conteúdo enviado pelo TinyMCE sem simplesmente desligar todo o processamento.
A possibilidade de utilizar essa configuração e o arquivo em que ela deve ser definida dependem das permissões e da configuração do servidor.
Como validar a solução
Para confirmar o diagnóstico, utilize um conteúdo simples no TinyMCE que contenha formatação inline:
<p style="color: red; text-align: center;">Teste do TinyMCE</p> |
Primeiro, envie esse conteúdo nas condições em que o erro 403 ocorre.
Depois, desative temporariamente o ModSecurity pelo método disponível no servidor e repita exatamente o mesmo teste.
Se o conteúdo for salvo normalmente após a desativação, o resultado confirma que o problema está relacionado às regras aplicadas pelo ModSecurity.
Para um diagnóstico mais preciso, o próximo passo deve ser consultar os logs do servidor e identificar a regra específica que foi acionada.
Resumo prático
O problema ocorria ao utilizar o TinyMCE para enviar conteúdo HTML contendo o atributo style="". Nessas condições, o servidor retornava 403 Forbidden.
O diagnóstico mostrou que o problema estava relacionado ao ModSecurity. Ao adicionar o seguinte conteúdo ao arquivo .htaccess localizado na raiz do sistema, a requisição passou a funcionar:
<IfModule mod_security.c> SecRuleEngine Off </IfModule> |
O mesmo resultado foi obtido ao desativar o ModSecurity diretamente pelo cPanel.
Portanto, se o TinyMCE funciona normalmente, mas determinadas tags ou atributos HTML fazem a requisição retornar erro 403, vale verificar se o ModSecurity está bloqueando o conteúdo antes de modificar o editor ou o código da aplicação.
Para ambientes de produção, porém, o ideal é utilizar a desativação apenas como diagnóstico e posteriormente identificar a regra responsável pelo falso positivo, mantendo as demais proteções do ModSecurity ativas.