Configurare WAF, ModSecurity e Permessi File per Sbloccare REST API e admin-ajax in Elementor

Quando si lavora con l’editor visivo di Elementor, uno dei problemi più critici e frustranti è l’impossibilità di salvare le modifiche o il blocco completo del caricamento dell’interfaccia con la rotella che gira all’infinito. In una consistente percentuale di casi, il problema non risiede in un conflitto fra script o in carenze di memoria PHP, bensì nelle barriere perimetrali di sicurezza del server: Web Application Firewall (WAF), moduli come Apache ModSecurity o permessi del filesystem errati. In questa guida tecnica vedremo i passaggi operativi per sbloccare REST API e admin-ajax intervenendo direttamente sulle configurazioni del web server e dei livelli firewall, integrando le nozioni esposte nella nostra guida completa alla schermata bianca e al caricamento infinito di Elementor.

Perché ModSecurity e i WAF Intercettano Elementor

La struttura dei payload JSON e le firme di attacco

Elementor comunica costantemente con il backend di WordPress inviando pacchetti dati in formato JSON tramite l’endpoint nativo /wp-json/elementor/v1/ o indirizzando richieste POST asincrone verso /wp-admin/admin-ajax.php. All’interno di questi payload viaggiano frammenti di codice HTML, attributi CSS inline, script personalizzati e talvolta query dinamiche. I sistemi di rilevamento delle intrusioni come ModSecurity o i WAF cloud analizzano il traffico in transito confrontandolo con serie di regole predefinite, come il Core Rule Set (CRS) di OWASP. Spesso stringhe come <script>, stili complessi o parametri serializzati vengono scambiati erroneamente per tentativi di SQL Injection (SQLi) o Cross-Site Scripting (XSS), scatenando un falso positivo immediato.

Identificare l’errore HTTP 403 e 406 nella console di sviluppo

Per diagnosticare con assoluta certezza se il blocco è imputabile alla sicurezza perimetrale, apri la pagina di modifica con Elementor, premi F12 su Google Chrome o Mozilla Firefox per accedere a DevTools e seleziona la scheda Network. Se durante il salvataggio visualizzi chiamate verso admin-ajax.php o percorsi /wp-json/ evidenziate in rosso con codice di stato 403 Forbidden, 406 Not Acceptable o 500 Internal Server Error generato da filtri a monte, sei in presenza di un blocco di sicurezza.

Configurare ModSecurity e Whitelistare le Regole

Individuare l’ID della regola violata nei log di audit

Non bisogna mai disattivare interamente ModSecurity sull’hosting, poiché priverebbe il CMS di una protezione fondamentale contro exploit noti. La prassi corretta consiste nell’estrarre l’ID numerico della regola che genera il falso positivo esaminando l’audit log del server HTTP (Apache, Nginx o LiteSpeed). Se possiedi accesso SSH con privilegi root o un pannello come cPanel o Plesk, visualizza il file di log:

tail -n 100 /var/log/apache2/modsec_audit.log | grep -E "(wp-json|admin-ajax.php)"

All’interno delle voci troverai un pattern contenente la dicitura [id "941100"] o [id "942100"], identificativo univoco della direttiva scatenata.

Disabilitare le regole problematiche tramite .htaccess o configurazione Apache

Una volta ottenuto l’ID della regola (ad esempio 941100 e 942100), puoi istruire il server affinché non applichi tali controlli sugli endpoint critici del builder. Aggiungi il seguente blocco di direttive nel file .htaccess situato nella cartella root del tuo sito WordPress:

<IfModule mod_security2.c>
  <LocationMatch "/(wp-admin/admin-ajax\.php|wp-json/elementor/)">
    SecRuleRemoveById 941100 942100 981176
  </LocationMatch>
</IfModule>

Su server gestiti tramite LiteSpeed Web Server (LSWS), è preferibile inserire la direttiva specifica:

<IfModule Litespeed>
  SecFilterEngine Off
  SecFilterScanPOST Off
</IfModule>

Avviso di sicurezza: Evita categoricamente di disabilitare ModSecurity a livello globale su tutto il dominio. Isola le esclusioni esclusivamente ai percorsi admin-ajax.php e alle route REST relative a Elementor, specificando se possibile l’accesso ai soli utenti autenticati con cookie di sessione amministrativa.

Gestione dei WAF Cloud e Plugin di Sicurezza Applicativa

Configurare regole WAF personalizzate su Cloudflare

Se utilizzi un proxy CDN come Cloudflare, le funzionalità di Managed Rules possono bloccare le chiamate REST prima che raggiungano il server di origine. Per consentire il traffico dell’editor visivo, recati nella dashboard di Cloudflare sotto Security > WAF > Custom Rules e crea una nuova eccezione mirata:

  1. Assegna un nome chiaro alla regola (es. Bypass Elementor REST and Ajax).
  2. Imposta l’espressione di corrispondenza del campo: (http.request.uri.path contains "/wp-admin/admin-ajax.php" or http.request.uri.path contains "/wp-json/elementor/") and ip.src in {IL_TUO_INDIRIZZO_IP_STATICO}.
  3. Sotto il campo Action, seleziona Skip e spunta tutte le funzionalità di WAF gestito (Managed Rules).

Configurare correttamente le eccezioni su Cloudflare è cruciale per sbloccare REST API e admin-ajax senza compromettere la protezione globale del sito.

La modalità di apprendimento in Wordfence e iThemes Security

Quando il WAF opera a livello applicativo tramite plugin PHP (come Wordfence Security o Solid Security), i payload di Elementor possono essere intercettati prima dell’elaborazione di WordPress. In Wordfence, naviga su Firewall > All Firewall Options > Basic Firewall Options e imposta temporaneamente lo stato su Learning Mode. Apri l’editor di Elementor, modifica una pagina complessa, salva i contenuti e pubblica le modifiche. Wordfence memorizzerà la struttura delle chiamate considerandole sicure. Al termine, reimposta immediatamente il firewall su Enabled and Protecting.

Permessi File e Proprietà Unix del Web Server

Applicare i permessi corretti su file e directory

Anche con un firewall perfettamente allineato, una configurazione restrittiva del filesystem Linux può impedire la corretta esecuzione di script asincroni o la scrittura di stili CSS rigenerati da Elementor nella cartella /wp-content/uploads/elementor/. I permessi standard per WordPress sono:

  • Directory: 755 (rwxr-xr-x)
  • File: 644 (rw-r–r–)
  • wp-config.php: 600 o 640

Ripristinare i corretti permessi Unix rappresenta un prerequisito obbligatorio per sbloccare REST API e admin-ajax sui server Linux con configurazioni restrittive. Puoi reimpostarli rapidamente tramite terminale SSH posizionandoti nella cartella radice dell’installazione:

find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;

Verificare il proprietario dei processi (chown) e FastCGI

Un errore frequente durante le migrazioni o dopo restore di backup manuali è la disconnessione tra l’utente che esegue il processo PHP-FPM o FastCGI (spesso www-data, nginx o l’utente di cPanel) e il proprietario effettivo dei file. Se il web server non dispone dei permessi di lettura ed esecuzione su wp-admin/admin-ajax.php, restituirà immancabilmente un errore 403 Forbidden:

chown -R www-data:www-data /var/www/html/

Assicurati che la configurazione del tuo pool PHP-FPM (/etc/php/X.X/fpm/pool.d/www.conf) definisca parametri listen.owner e listen.group identici all’utente di sistema assegnato alla root del sito.

Riepilogo e Best Practice per la Manutenzione

L’integrazione fluida tra plugin di page building e hardening del server richiede un equilibrio millimetrico tra sicurezza attiva e tolleranza operativa. Seguendo questa checklist tecnica sarai in grado di sbloccare REST API e admin-ajax ed evitare per sempre il blocco dell’editor visivo, mantenendo invariati i protocolli di difesa contro tentativi di intrusione reali.

FAQ Tecniche su Elementor, WAF e REST API

Come capisco se il blocco proviene da ModSecurity o da Cloudflare?

Verifica l’intestazione della risposta HTTP nella scheda Network dei DevTools del browser. Se la risposta 403 presenta intestazioni come Server: cloudflare e restituisce una pagina HTML brandizzata con un Cloudflare Ray ID, il blocco avviene sul server proxy di Cloudflare. Se invece ricevi una pagina Apache/LiteSpeed standard o un errore JSON con indicazione generica, il blocco è scatenato localmente dal demone web (ModSecurity) o da un plugin interno.

Perché la disattivazione del WAF non risolve subito l’errore in Elementor?

Spesso le risposte 403 vengono memorizzate nella cache del browser o nei sistemi di caching intermedi (Object Cache come Redis/Memcached o cache FastCGI a livello Nginx). Dopo aver applicato le modifiche al file .htaccess o alla configurazione del WAF, svuota la cache del browser, purga completamente la cache del web server e rigenera i file CSS da Elementor > Strumenti > Rigenera file e dati.

Posso inserire l’indirizzo IP del server in whitelist per risolvere i problemi di admin-ajax?

No, perché le chiamate asincrone di Elementor durante la sessione di editing non provengono dal server stesso (chiamate loopback/cURL), ma direttamente dal computer client dell’amministratore connesso via browser. L’IP da inserire in whitelist o da considerare nelle eccezioni personalizzate del firewall è sempre l’IP pubblico del router da cui ti stai collegando all’area amministrativa di WordPress.

Articoli simili