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: le API Cloudflare hanno limiti abbastanza generosi, ma con molte zone in parallelo è meglio implementare un throttle esplicito nel workflow N8N per evitare errori 429 su account grandi.