Vérifier la validité des données d'un Webhook sur n8n

Introduction

Les webhooks dans n8n ou autres (make, ...), sont supers pratiques pour déclencher des scénarios à la demande. Mais on voit souvent des implémentations ou la sécurité est tout simplement absente ou très légère !

La première étape pour mettre en place un webhook est bien sur de gérer l'authentification via un header auth ou via un jeton JWT. Cela permet d'éviter de laisser n'importe qui accéder au webhook et de n'importe où surtout !

L'appel du webhook ne doit surtout pas se faire depuis un front public sauf si vous avez vraiment une bonne raison mais doit passer par un backend ou à défaut, par un service intermédiaire type fonction lambda ou par exemple les edges functions de supabase ou encore function de cloudflare... (il y en a beaucoup d'autres) dont le but sera de contrôler et d'offusquer l'appel http vers notre instance n8n.

La seconde étape consiste à valider le contenu de la requête par la vérification de la signature HMAC du body et le timestamp d'émission. Ceci pour garantir la non altération des données transmises.

Bonus, nous verrons comment implémenter un accès rate control directement dans le workflow n8n. Idéalement, il faudrait gérer ca coté web serveur ou via le backend du site web envoyant le wehook mais parfois ce n'est pas faisable.

Hmac

La vérification de la signature HMAC consiste à encoder le contenu du corps de la requête (body) côté backend à l’aide d’une clé secrète, puis à refaire le même encodage côté n8n avec cette même clé.

On compare ensuite les deux signatures : si elles ne correspondent pas, cela signifie que le contenu du body a été intercepté ou modifié pendant le transfert.

Dans ce cas, la requête doit être bloquée et une erreur renvoyée pour signaler l’anomalie.

Exemple coté backend ici en php :

$data = [
        'param1' => $param1,
        'param2' => $param2,
    ];
	
$body_signature = json_encode($data, JSON_UNESCAPED_SLASHES);
$body = json_encode($data);

$signature_hmac = hash_hmac('sha256', $body_signature, $hmac_secret);
    
$args = [
    'method' => 'POST',
    'headers' => ['Content-Type' => 'application/json', 'APIKEY' => APIKEY, 'X-Hub-Signature-256' => $signature_hmac, 'X-Signature-Timestamp' => time()],
    'body' => $body,
    'timeout' => 10,
    'sslverify' => true
];

Deux nœuds sont utilisés dans n8n pour effectuer la comparaison de signature.

Le noeud "crypto" et le noeud "if" pour valider.

Dans le nœud crypto, on récupère le body du webhook et on encode avec la même clé (HMAC_SECRET) que celle utilisée dans le backend.

Le nœud if permet simplement de valider l'exactitude des deux signatures.

• Si ce n'est pas conforme "False", on renvoi vers une sortie erreur.
• Si conforme "True", on peut continuer le workflow.

Timestamp

La vérification du timestamp permet d’éviter le traitement de données trop anciennes, potentiellement obsolètes ou renvoyées par erreur.

Cependant, cette approche peut poser problème si des requêtes légitimes subissent un retard d’envoi par exemple en raison d’une latence réseau ou d'un service bloqué et que leur timestamp dépasse le délai autorisé.

Il est donc important de déterminer si ce contrôle doit être strictement bloquant ou informatif, selon le niveau de tolérance souhaité pour ton workflow.

Rate-Limit

Mon instance n8n dispose d’un accès local à une base de données de type MySQL/MariaDB, ce qui permet d’exécuter des requêtes avec une latence très faible.
Je l’utilise pour mettre en place un système de rate-limit configurable par workflow.

L’idéal serait d’utiliser une base de caching type Redis, encore plus rapide pour ce type de traitement, mais la solution actuelle remplit très bien son rôle à mon échelle.

On pourrait également explorer les Data tables récemment introduites dans n8n, qui offrent de nouvelles possibilités intéressantes pour ce genre de besoin.

Pour mieux faire, il faudrait introduire une clé supplémentaire pour contrôler le rate-limit par workflow ou par task.

Résumé

Mettre en place des webhooks sécurisés dans n8n ne requiert pas forcément des moyens techniques complexes, mais cela demande un minimum de rigueur et le respect de bonnes pratiques.
Un webhook mal protégé peut devenir une porte d’entrée vers des abus, des requêtes non autorisées ou des manipulations de données indésirables. En anticipant ces risques dès la conception, on renforce non seulement la sécurité de l’infrastructure, mais aussi la fiabilité des automatisations mises en place.

Bien sûr, aucune solution n’est totalement infaillible. Cependant, en appliquant des mécanismes simples comme l'authentification, la vérification des signatures, la validation du timestamp et un rate-limit. On peut considérablement réduire la surface d’attaque et gagner en sérénité.

En somme, un peu de prévention vaut largement le temps investi pour anticiper au maximum les problèmes plutôt que de devoir les corriger en urgence.