ModSecurity blocca WordPress: come diagnosticare il 403

In breve: un 403 causato da ModSecurity si riconosce correlando la richiesta bloccata con l’ID della regola registrato nell’audit log. Non basta disattivare un plugin o ModSecurity: bisogna riprodurre una sola richiesta, identificare regola, parametro e payload, quindi correggere la richiesta oppure applicare un’esclusione limitata.

Indice dei contenuti

• Come capire se il 403 viene da ModSecurity
• Dati da annotare durante la prova
• Diagnosi passo per passo
• Correzione sicura
• Verifica finale
• Domande frequenti
• Fonti tecniche

Come capire se il 403 viene da ModSecurity

Lo stesso codice HTTP può essere generato da WordPress, da un plugin di sicurezza, dal web server, da una CDN o dal WAF. L’indizio decisivo è una voce di log nello stesso secondo della richiesta, con identificativo della regola e parte della transazione che ha attivato il blocco.

• Il 403 compare sempre sulla stessa URL o azione, per esempio salvataggio, upload o chiamata REST.
• Una richiesta semplice funziona, mentre quella contenente uno specifico campo o file viene bloccata.
• Nel log ModSecurity compare un evento con lo stesso host, URI e orario.

Dati da annotare durante la prova

• URL e metodo HTTP, senza token o dati personali.
• Orario preciso con fuso orario.
• Stato 403 e, se disponibile, request ID.
• ID e messaggio della regola ModSecurity.
• Nome del campo, tipo di file o frammento che attiva il controllo.

Diagnosi passo per passo

1. Riproduci una sola volta. Usa un account di prova e un contenuto non sensibile; annota l’orario prima di inviare.
2. Controlla la risposta. In DevTools apri Network e verifica URL, metodo e codice. Non copiare cookie o header Authorization.
3. Cerca la transazione nel log. Correlala per orario, host e URI; individua rule ID, fase e variabile coinvolta.
4. Riduci il caso. Rimuovi un campo o usa un file innocuo per capire quale parte del payload attiva la regola.
5. Escludi conflitti applicativi in staging. Se nel log WAF non esiste una transazione corrispondente, controlla plugin di sicurezza, permessi e regole del web server.

Correzione sicura

Correggi prima la richiesta quando contiene markup, query o dati non necessari. Se è un falso positivo confermato, l’eccezione deve riferirsi alla singola regola e, quando possibile, alla sola URL o variabile. Evita di spegnere ModSecurity per l’intero dominio.

• Aggiorna il componente che genera una richiesta non valida o obsoleta.
• Limita l’esclusione all’ID della regola confermata.
• Documenta motivazione, URL, parametro e data della modifica.
• Mantieni attive le altre regole e verifica che richieste malevole continuino a essere bloccate.

Se non gestisci direttamente il WAF, invia al provider URI, metodo, orario, request ID e rule ID. Non allegare l’intero payload quando contiene dati personali: è sufficiente indicare la variabile e usare un valore di prova riproducibile.

Verifica finale

1. Ripeti la stessa azione legittima due volte.
2. Controlla che entrambe terminino senza 403.
3. Verifica il log: la regola esclusa non deve scattare sul caso autorizzato e il WAF deve continuare a registrare le altre protezioni.
4. Controlla che salvataggio, upload o endpoint coinvolti restituiscano il risultato atteso.

Domande frequenti

Fonti tecniche

• OWASP Core Rule Set — False positives and tuning
• OWASP ModSecurity — Reference Manual

Guide Xlogic correlate

• Gestire ModSecurity in cPanel
• ModSecurity 403: falso positivo
• Errore 403 Forbidden