WooCommerce wc-ajax restituisce 403 Forbidden

In breve: un errore WooCommerce wc-ajax 403 indica che una richiesta AJAX del negozio è stata rifiutata. Per trovare la causa bisogna identificare la richiesta esatta nel browser e stabilire se il 403 proviene da WordPress, da un plugin di sicurezza, dalla cache, dal WAF del server o da un proxy esterno.

Che cosa significa wc-ajax 403

WooCommerce usa endpoint AJAX sul front-end per operazioni dinamiche come carrello e checkout. Nelle pagine basate sul checkout classico una richiesta può avere una query simile a ?wc-ajax=update_order_review; i blocchi Cart e Checkout più recenti possono invece usare la Store API.

Il codice 403 significa che il livello che ha ricevuto la richiesta ha deciso di non autorizzarla. Non identifica da solo il responsabile: occorre esaminare URL, risposta e log alla stessa ora.

Identificare la richiesta che fallisce

1. Apri una finestra privata e riproduci il problema con un prodotto di prova.
2. Apri gli strumenti per sviluppatori del browser e seleziona Network.
3. Filtra le richieste per Fetch/XHR e cerca wc-ajax oppure richieste alla Store API.
4. Individua quella con stato 403 e annota URL, metodo, azione, ora e passaggio del checkout.
5. Salva il testo della risposta eliminando cookie, nonce, dati personali e informazioni di pagamento.

Verifica sia come visitatore anonimo sia con un account cliente. Se il problema compare soltanto in una delle due condizioni, la sessione, i cookie o una regola dedicata agli utenti autenticati diventano indizi importanti.

Leggere risposta e intestazioni

Apri la richiesta e controlla le sezioni Headers e Response. Una pagina HTML del proxy, un messaggio ModSecurity, un errore JSON di WooCommerce o una risposta generata da un plugin portano a diagnosi diverse.

• Una pagina del CDN o del proxy richiede il controllo nel relativo firewall.
• Un riferimento a una regola WAF deve essere confrontato con gli eventi di sicurezza del server.
• Un messaggio su nonce o sessione richiede di verificare cookie, cache e durata della pagina.
• Una risposta vuota va correlata con access log, error log PHP e log di WordPress.

Sessione, cookie e nonce

Svuota il carrello, chiudi la sessione privata e ripeti la prova. Controlla che WordPress Address e Site Address usino lo stesso schema HTTPS e lo stesso host previsto; passaggi incoerenti tra HTTP/HTTPS o tra www e dominio principale possono impedire l’invio dei cookie corretti.

Se il problema è iniziato dopo un aggiornamento, svuota le cache e accertati che tema, WooCommerce e gateway di pagamento siano compatibili. Non sostituire o disabilitare controlli nonce nel codice per aggirare il 403: prima va corretta la causa della sessione non valida.

Controllare cache e CDN

Carrello, checkout e area account contengono dati specifici della sessione e non devono essere serviti come pagine statiche condivise. Verifica le esclusioni del plugin cache, di LiteSpeed Cache e dell’eventuale CDN.

1. escludi gli URL di carrello, checkout e account dalla page cache;
2. non memorizzare risposte AJAX o API che dipendono dalla sessione;
3. svuota cache applicativa, server e CDN;
4. ripeti una prova anonima completa senza riutilizzare la vecchia sessione.

Una prova con la cache disattivata deve essere temporanea e controllata. Se risolve il problema, ripristina la cache con esclusioni mirate invece di lasciarla completamente disabilitata.

Controllare WAF e plugin di sicurezza

Conserva l’orario preciso del 403 e cerca l’evento corrispondente nel WAF, in ModSecurity o nel plugin di sicurezza. Annota ID della regola, percorso e parametro coinvolto, senza copiare dati del cliente.

Se una regola produce un falso positivo, crea o richiedi un’eccezione limitata alla regola e all’endpoint necessario. Non disattivare globalmente ModSecurity, il firewall o la protezione del sito per far funzionare il checkout.

Controlla anche regole geografiche, limitazioni di frequenza e protezioni anti-bot del CDN: un checkout può eseguire più richieste ravvicinate e venire bloccato da una soglia troppo aggressiva.

Isolare un conflitto in staging

Se log e WAF non spiegano il 403, crea una copia staging e procedi per esclusione:

1. aggiorna il backup e riproduci il problema nello staging;
2. passa temporaneamente a un tema WooCommerce compatibile;
3. disattiva i plugin non essenziali, lasciando WooCommerce e il componente necessario al test;
4. riattiva un componente alla volta finché il 403 ricompare;
5. controlla personalizzazioni in tema child, snippet e mu-plugin.

Non eseguire questa prova sul negozio in produzione durante gli ordini: potrebbe alterare checkout, pagamenti e sessioni dei clienti.

Verifica finale del negozio

Dopo la correzione esegui un ciclo completo come utente anonimo e autenticato: aggiunta e rimozione prodotto, modifica quantità, calcolo spedizione, applicazione coupon e checkout di prova con un metodo sicuro. La scheda Network non deve più mostrare 403 e le risposte AJAX devono avere il formato atteso.

Rimuovi gli strumenti di debug temporanei, riattiva le protezioni non coinvolte e conserva la modifica mirata applicata. Controlla inoltre che non siano comparsi nuovi errori nei log.

Guide Xlogic correlate

• WooCommerce: ordine con stato Fallito
• Email WooCommerce non inviate o ricevute
• WooCommerce nonce verification failed nel checkout

Domande frequenti

Fonti

• WooCommerce Developer — Endpoint wc-ajax
• WooCommerce — Diagnosi delle richieste AJAX del checkout
• WooCommerce — Esclusioni cache per carrello e checkout