Gestisci più di tre domini su Cloudflare e sai già dove voglio arrivare: la prima volta che devi replicare una regola WAF su venti proprietà ti metti lì a farlo a mano, giuri che non lo farai mai più, e poi lo rifai tre mesi dopo.

Questo è il post che spiega come ho risolto il problema in modo definitivo: una dashboard HTML con un workflow N8N self-hosted come backend, senza spendere un euro.

Il problema

In _blank gestiamo una cinquantina di domini attivi su Cloudflare, tra clienti e progetti interni. Ogni tanto emerge una nuova minaccia (bot aggressivi, scraper, pattern d’attacco specifici) e dobbiamo costruire una regola WAF custom per bloccarla.

Il problema non è creare la regola. È replicarla.

L’interfaccia di Cloudflare non offre nessuno strumento nativo per copiare regole tra zone. Puoi esportare un ruleset JSON, andare sulla zona target, importarlo, verificare che non ci siano conflitti con regole già esistenti. Moltiplicato per dieci domini diventa una procedura di venti minuti che fai sempre in fretta e sempre con qualche errore.

La soluzione enterprise (le regole a livello account) richiede un piano Enterprise da migliaia di euro al mese. Scartata.

La soluzione

Esistono già alcuni tool per questo problema: ConfigBerry offre un’interfaccia online, altri approcci usano script Python da CLI. Il problema dei tool online è che richiedono di inserire il proprio API token Cloudflare su un sito di terze parti. Gli script CLI funzionano, ma non hai nessuna visibilità su cosa sta per succedere prima di eseguire.

Ho quindi costruito qualcosa di diverso: un tool self-hosted con interfaccia visuale, dove le credenziali restano nella tua infrastruttura e puoi vedere esattamente cosa cambierà prima di toccare qualcosa. Stack minimalista:

  • Frontend: HTML standalone con React via CDN, Tailwind per lo stile. Si apre nel browser, nessun server necessario.
  • Backend: Workflow N8N self-hosted come proxy verso le API Cloudflare (necessario per aggirare il CORS del browser, e per tenere il token fuori dal frontend).
  • Deploy: Zero costi aggiuntivi se hai già N8N. Il file HTML funziona in locale o hostato su qualsiasi CDN statica.

Il flusso è volutamente lineare: scegli la zona sorgente, selezioni una regola, il tool scansiona automaticamente tutte le altre zone e ti dice lo stato di ognuna, poi sincronizzi in un click.

Come funziona: step by step

1. Selezione zona sorgente e regola

Apri il tool, che carica automaticamente tutte le zone dal tuo account Cloudflare via API. Selezioni la zona da cui vuoi prendere la regola, e il tool carica il ruleset WAF custom con nome, espressione e azione di ogni regola.

2. Scansione automatica delle zone target

Qui sta la parte interessante. Nel momento in cui selezioni una regola, il tool non ti chiede “dove vuoi metterla?” ma prima scansiona tutte le zone rimanenti e classifica ognuna in tre stati:

Identica: la regola è già presente con la stessa espressione e la stessa azione. La zona viene esclusa automaticamente dalla sincronizzazione, non c’è niente da fare.

Parziale: esiste una regola simile (stesso nome, o espressione con un match ≥40% delle clausole, o stessa azione). Il tool la auto-seleziona in modalità Sostituisci, puntando alla regola corrispondente. Cliccando su “Dettagli” vedi un diff side-by-side tra le due espressioni.

Assente: nessuna corrispondenza trovata. Auto-selezionata in modalità Aggiungi.

Il riepilogo in alto ti dice subito: “3 identiche, 2 parziali, 5 assenti.” Il pulsante di sync mostra il breakdown delle operazioni prima di eseguire qualsiasi cosa.

3. Review e override manuale

Per ogni zona puoi cambiare manualmente la modalità (da Sostituisci ad Aggiungi se vuoi tenere entrambe le versioni) o deselezionare zone specifiche. Nessun automatismo cieco: vedi sempre cosa sta per succedere prima di cliccare.

4. Sincronizzazione

Il tool invia ogni operazione al webhook N8N, che gestisce le chiamate alle API Cloudflare con il token appropriato. Per ogni zona ricevi feedback in tempo reale: successo, errore, o skip se la zona era già allineata.

Il workflow N8N

Sul lato backend ho costruito un singolo workflow N8N con un webhook come entry point. Riceve un body JSON con un campo action e smista la richiesta al branch corretto tramite un nodo Switch.

Autenticazione

Tutte le chiamate alle API Cloudflare usano un Bearer token nell’header Authorization. Il token viene salvato come credenziale in N8N e iniettato dai nodi HTTP Request, senza mai passare per il frontend. Per questo progetto servono i permessi Zone.Firewall Services (Edit) e Zone.Zone (Read).

Le quattro action

list-zones chiama GET /client/v4/zones?per_page=50 e restituisce l’array di zone con id e name. Se hai più di 50 zone devi gestire la paginazione, ma per la maggior parte degli account un’unica chiamata basta.

list-rules chiama GET /client/v4/zones/{zone_id}/rulesets/phases/http_request_firewall_custom/entrypoint e restituisce il ruleset WAF custom della zona. La risposta contiene un array rules, dove ogni regola ha id, description, expression e action. Se la zona non ha ancora un ruleset custom, Cloudflare restituisce un 404: N8N lo gestisce con un nodo IF e ritorna un array vuoto invece di un errore.

add-rule usa PATCH /client/v4/zones/{zone_id}/rulesets/phases/http_request_firewall_custom/entrypoint con un body che aggiunge la regola in append all’array esistente:

{
  "rules": [
    {
      "description": "Nome regola",
      "expression": "espressione firewall",
      "action": "block",
      "enabled": true
    }
  ]
}

Attenzione: l’endpoint PATCH per i ruleset Cloudflare è additivo solo se usi la struttura corretta. Se passi l’intero array rules invece di un singolo elemento, sovrascrive tutto il ruleset. Il workflow gestisce questo recuperando prima il ruleset esistente, aggiungendo la nuova regola all’array, e facendo un PATCH con l’array completo aggiornato.

replace-rule segue la stessa logica: recupera il ruleset, trova la regola da sostituire per id, la aggiorna con la nuova expression e action, e fa il PATCH con l’array aggiornato.

Gestione degli errori

Ogni branch ha un nodo di error handling che intercetta i 4xx e 5xx di Cloudflare e li restituisce al frontend con un messaggio leggibile. In questo modo il tool HTML può mostrare “Errore 429: rate limit” o “Errore 403: permessi insufficienti” invece di un generico fallimento di rete.

Il token Cloudflare sta nell’environment di N8N e non transita mai nel frontend. Il file HTML non contiene credenziali di nessun tipo.

Risultati

Prima: replicare una regola su dieci domini richiedeva ~20 minuti, con alto rischio di dimenticare una zona o creare duplicati.

Dopo: 90 secondi. Seleziono la regola, verifico il riepilogo, click su “Sincronizza” e ricevo il feedback per ogni zona.

Il tool gestisce correttamente i casi edge più fastidiosi: zone che hanno già la regola (skip automatico), zone con una versione parziale (diff visivo + sostituzione mirata), zone su cui la chiamata API fallisce (errore isolato senza bloccare le altre).

Cosa migliorerei

Sincronizzazione di gruppo: oggi puoi selezionare solo una regola per volta. Avrebbe senso poter selezionare un set di regole e sincronizzarle tutte insieme in una sola operazione.

Storico delle operazioni: non c’è nessun log persistente. Se vuoi sapere quando e cosa hai sincronizzato, devi andare su N8N e leggere l’execution history manualmente.

Auth delegata: il token Cloudflare è unico e deve avere accesso a tutte le zone. Per configurazioni multi-account servirebbe un sistema di gestione token più granulare.

Rate limiting: “abbastanza generosi” non è un numero, quindi tanto vale prendere quello vero. La documentazione Cloudflare sui rate limit dice:

The global rate limit for the Cloudflare API is 1,200 requests per five minute period per user

e sul superamento del limite:

If you exceed this limit, all API calls for the next five minutes will be blocked

Il conteggio è per utente e cumulativo su dashboard, chiave API e token: non hai 1.200 richieste solo per il tuo workflow, le condividi con quello che stai facendo a mano nel pannello nello stesso momento. Con una ventina di zone il sync ne consuma poche decine e il margine resta ampio, ma su account con centinaia di zone conviene un throttle esplicito nel workflow N8N: il blocco non riguarda la singola chiamata che sfora, riguarda tutte le chiamate dei cinque minuti successivi.

Domande frequenti

Si possono copiare le regole WAF di Cloudflare tra più zone senza un piano Enterprise?

Cloudflare non ha uno strumento nativo per copiare regole tra zone: si esporta il ruleset in JSON e lo si importa a mano su ogni zona, con il rischio di conflitti. Le regole a livello account richiedono un piano Enterprise. La soluzione descritta qui è una dashboard HTML con un workflow N8N self-hosted come backend, che scansiona le altre zone, mostra cosa cambierà e sincronizza. Per replicare una regola su dieci domini si passa da circa 20 minuti a 90 secondi.

Quali permessi servono al token Cloudflare per sincronizzare le regole WAF?

Servono Zone.Firewall Services (Edit) e Zone.Zone (Read). Il token viene salvato come credenziale in N8N e iniettato dai nodi HTTP Request, quindi non transita mai nel frontend e il file HTML non contiene credenziali. Il limite è che il token è unico e deve avere accesso a tutte le zone: per configurazioni multi-account servirebbe una gestione più granulare.

Perché il PATCH dei ruleset di Cloudflare può cancellare le regole esistenti?

L'endpoint PATCH dei ruleset è additivo solo se si usa la struttura corretta: passando l'intero array rules invece di un singolo elemento si sovrascrive tutto il ruleset. Il workflow evita il problema recuperando prima il ruleset esistente, aggiungendo o sostituendo la regola nell'array e facendo il PATCH con l'array completo aggiornato. Se la zona non ha ancora un ruleset custom, Cloudflare risponde 404 e il workflow lo tratta come un array vuoto.

Quante richieste all'API di Cloudflare si possono fare prima di essere bloccati?

La documentazione Cloudflare indica un limite globale di 1.200 richieste ogni cinque minuti per utente, cumulativo su dashboard, chiave API e token. Superato il limite, tutte le chiamate dei cinque minuti successivi vengono bloccate, non solo quella che sfora. Con una ventina di zone la sincronizzazione ne consuma poche decine, ma su account con centinaia di zone conviene un throttle esplicito nel workflow N8N.