Come proteggere endpoint wc ajax da attacchi DoS

I negozi online basati su WooCommerce gestiscono decine di richieste asincrone ogni minuto. In questa guida tecnica vedremo come proteggere endpoint wc ajax per prevenire sovraccarichi critici del database MySQL e del processo PHP-FPM. Se noti rallentamenti anomali, ti consigliamo di approfondire la nostra guida dedicata a ottimizzare get refreshed fragments per alleggerire subito il carrello.

Gli endpoint dinamici di WooCommerce non possono essere salvati nella normale cache di pagina. Di conseguenza, ogni singola richiesta colpisce direttamente il server web. Senza un solido sistema di limitazione delle richieste, un aggressore può saturare la CPU in pochi secondi.

Perché gli endpoint wc-ajax sono vulnerabili ai DoS

WooCommerce sfrutta il parametro URL ?wc-ajax= per coordinare azioni fondamentali. Tra queste troviamo l’aggiornamento del carrello, la selezione delle spedizioni e il checkout. Questa architettura rende il negozio estremamente dinamico ma introduce anche delle fragilità computazionali.

La natura non cachabile delle chiamate AJAX

I sistemi di caching come Varnish o Redis Page Cache bypassano queste chiamate. Il motivo è semplice: i dati del carrello appartengono alla sessione univoca del cliente. La richiesta attraversa l’intero stack software. WordPress carica il core, attiva i plugin ed esegue query complesse su database.

Un botnet a bassa intensità può inviare centinaia di chiamate al minuto. Questo volume non attiva i filtri anti-DDoS generici dei provider hosting. Tuttavia, genera carichi pesanti capaci di bloccare i visitatori reali.

L’impatto sul consumo di risorse PHP e MySQL

Ogni worker PHP-FPM richiede memoria RAM e tempo di esecuzione della CPU. Quando le chiamate concorrenti aumentano, la coda dei processi si riempie rapidamente. Il server risponde con errori 502 Bad Gateway o 504 Gateway Timeout.

Anche il database subisce un impatto diretto. Le tabelle wp_options e wp_woocommerce_sessions vengono interrogate ripetutamente. La saturazione del database porta al blocco totale dell’intero e-commerce.

Rate limiting tramite Web Server Nginx

Intervenire a monte dell’applicazione garantisce la massima efficienza sistemistica. Implementare regole a livello server rappresenta il metodo migliore per proteggere endpoint wc ajax prima che la richiesta tocchi PHP. Nginx offre un modulo nativo estremamente performante per questo scopo.

Configurazione della direttiva limit_req_zone

Apri il file di configurazione principale di Nginx, solitamente collocato in /etc/nginx/nginx.conf. All’interno del blocco http, definisci una zona di memoria dedicata al tracciamento degli indirizzi IP:

• limit_req_zone $binary_remote_addr zone=wc_ajax_limit:10m rate=5r/s;
• La zona assegna 10 megabyte di memoria per memorizzare gli stati degli IP.
• La direttiva imposta un limite prudente di 5 richieste al secondo per singolo client.

Implementare la regola sul blocco di WooCommerce

Ora apri il file di configurazione del tuo virtual host. Aggiungi una condizione specifica per intercettare le chiamate al parametro di query di WooCommerce:

• Verifica la presenza della stringa wc-ajax nella variabile $query_string.
• Applica la direttiva limit_req_zone con un buffer temporaneo di burst.
• Imposta il parametro nodelay per gestire picchi immediati senza ritardare i client legittimi.

Trucco operativo: Non impostare una soglia troppo restrittiva sul burst. Durante la navigazione, un cliente reale apre più schede e può generare 8-10 richieste contemporanee. Un valore di burst=12 nodelay garantisce un’eccellente tolleranza.

Protezione perimetrale con Cloudflare WAF

Fermare il traffico dannoso sul perimetro della rete riduce a zero il consumo delle risorse del tuo server. Configurare il WAF ti permette di proteggere endpoint wc ajax bloccando bot e crawler malevoli sul nascere. Cloudflare include un potente motore di Rate Limiting basato su regole personalizzate.

Creazione di una Custom Rate Limiting Rule

Accedi alla dashboard di Cloudflare e seleziona il tuo dominio. Naviga nella sezione Security e clicca su WAF, quindi seleziona la scheda Rate limiting rules. Crea una nuova regola con i seguenti passaggi precisi:

1. Assegna un nome chiaro alla regola, ad esempio “Protezione Rate Limit wc-ajax”.
2. Nel costruttore di espressioni, seleziona il campo URI Query String.
3. Imposta l’operatore su contains e inserisci il valore wc-ajax.
4. Imposta la soglia su 15 richieste nell’arco temporale di 10 secondi.
5. Scegli l’azione Managed Challenge per sottoporre i bot a verifica interattiva.

Gestione delle eccezioni per checkout e carrello

Non tutte le chiamate AJAX hanno lo stesso peso. Alcune azioni del carrello richiedono chiamate consecutive legittime. Puoi affinare l’espressione per proteggere solo gli endpoint più bersagliati:

• Isola l’azione specifica con la condizione URI Query String contains "wc-ajax=get_refreshed_fragments".
• Escludi gli indirizzi IP dei gateway di pagamento come Stripe o PayPal.
• Consenti il passaggio immediato agli utenti che hanno già superato una verifica CAPTCHA precedente.

Mitigazione a livello applicativo in WordPress

Se utilizzi un hosting condiviso o non hai accesso root al server, puoi agire via codice. Esistono anche tecniche applicative utili per proteggere endpoint wc ajax qualora non avessi pieno accesso all’infrastruttura server. Le transient API e i transient lock consentono di limitare le chiamate ripetute.

Disattivare get_refreshed_fragments quando non necessario

La chiamata get_refreshed_fragments è spesso la causa principale del sovraccarico. Viene eseguita su ogni pagina per aggiornare il carrello laterale. Puoi disabilitare questo script nelle pagine non commerciali come il blog o la home page:

• Verifica con la funzione condizionale is_cart() o is_checkout() il contesto della pagina.
• Rimuovi la coda dello script wc-cart-fragments tramite wp_dequeue_script.
• Sostituisci la logica dinamica con il salvataggio dei prodotti nel LocalStorage del browser.

Limitare le sessioni con snippet PHP

Puoi registrare un hook su init prima dell’elaborazione di WooCommerce. Questo frammento legge l’IP del client e utilizza un transient per memorizzare il contatore:

• Cattura l’IP del visitatore tramite $_SERVER['REMOTE_ADDR'].
• Incrementa il valore associato all’interno della cache transient con scadenza a 60 secondi.
• Se il conteggio supera le 30 chiamate al minuto, termina l’esecuzione inviando un header HTTP 429 Too Many Requests.

FAQ – Domande frequenti sulla sicurezza di wc-ajax

Il rate limiting può bloccare gli acquisti legittimi dei clienti?

Se configurato con soglie corrette, il sistema non interferisce con le vendite. I clienti umani non superano mai 3-4 richieste al secondo. Impostando un burst adeguato, la navigazione resta fluida e totalmente trasparente.

Qual è la soglia ideale di richieste al secondo?

Un’analisi approfondita del traffico reale è indispensabile per proteggere endpoint wc ajax senza generare falsi positivi. Consigliamo di iniziare con una soglia prudente di 10 richieste al secondo per IP. Monitora i log per 48 ore prima di abbassare il limite a valori più severi.

I plugin di sicurezza come Wordfence o iThemes possono gestire questo blocco?

Sì, ma con un’efficienza inferiore rispetto a Nginx o Cloudflare. I plugin di sicurezza intervengono quando PHP è già stato avviato. Consumano memoria preziosa anche solo per verificare e rifiutare la connessione.