- Votre site bloque cette saisie parce que le WAF Cloudflare la prend pour une tentative d’injection SQL ou pour des données malformées, ce qui constitue alors un faux positif.
- Un nombre élevé de requêtes ou une limitation de débit peuvent aussi déclencher le blocage, indépendamment du filtrage SQL.
- Retrouvez la règle responsable grâce au Ray ID dans le tableau Security Events, puis créez une exception ciblée plutôt que de désactiver l’ensemble du WAF.
Sommaire
- Un site web déclenche sa sécurité après une action suspecte, une commande SQL ou des données malformées
- Une injection SQL transforme une saisie en commande exécutée
- Les requêtes paramétrées séparent durablement les valeurs du code SQL
- Le WAF Cloudflare permet d’isoler la règle responsable d’un faux positif
Une saisie banale suffit parfois à faire bloquer votre site.
Votre site web a déclenché son système de sécurité après une action de l’utilisateur, et la cause reste floue. Je vais vous aider à la trouver et à la corriger sans affaiblir votre protection.
Un site web déclenche sa sécurité après une action suspecte, une commande SQL ou des données malformées
Cloudflare examine chaque requête HTTP adressée au site. Il regarde l’adresse IP, le chemin, les en-têtes et le contenu transmis. Selon la règle appliquée, l’accès est autorisé, vérifié ou bloqué.
Le blocage peut viser une saisie qui ressemble à une injection. Il peut aussi viser une commande SQL, un script automatisé ou une structure de données inhabituelle. La détection repose sur des signatures d’attaque. Plusieurs règles évaluent aussi le niveau de risque.
Des données malformées suffisent parfois à déclencher le système.
Quatre cas typiques :
- un JSON invalide
- un en-tête inattendu
- un paramètre répété de façon anormale
- un corps de requête difficile à analyser
La requête peut alors être stoppée avant d’atteindre l’application du site.
Le contexte compte aussi. Un nombre élevé de demandes en peu de temps peut activer une protection distincte du filtrage SQL. Il en va de même pour une navigation proche de celle d’un robot, une adresse IP signalée ou une limitation de débit.
Un faux positif désigne une action légitime que le système prend pour une menace. Par exemple, un formulaire contient des caractères utilisés dans les requêtes. Ou bien un fichier a un contenu qui ressemble à une charge malveillante.
Les règles inspectent le corps d’une requête jusqu’à une taille maximale. Cette taille dépend de l’offre Cloudflare. Un contenu très long multiplie les correspondances avec les règles de sécurité.
Avant de répéter la saisie, évitez de renvoyer plusieurs fois le même formulaire. Ne relancez pas non plus un script automatiquement.
Conservez ensuite les éléments utiles :
- le texte utilisé
- l’heure du blocage
- l’adresse de la page
- une capture du message affiché
Contactez ensuite le propriétaire du site par e-mail. Décrivez l’action effectuée et indiquez le message reçu. Transmettez aussi le Cloudflare Ray ID visible en bas de la page. Cet identifiant permet de retrouver la requête concernée.
Une injection SQL transforme une saisie en commande exécutée
Une injection SQL apparaît quand votre application assemble une requête avec des données saisies par l’utilisateur. Le code SQL et les valeurs ne sont pas séparés. La saisie peut alors changer le sens de la requête.
Prenons une recherche vulnérable. La valeur tom’ OR ‘1’=’1 ferme la chaîne de caractères trop tôt. Elle ajoute ensuite une condition toujours vraie. Le serveur exécute alors une logique différente de celle prévue.
Une injection réussie peut exposer les données des tables accessibles : comptes, adresses, commandes. Selon les droits obtenus, elle permet aussi de modifier, supprimer ou extraire des informations.
Les requêtes paramétrées séparent durablement les valeurs du code SQL
La protection prioritaire repose sur les requêtes paramétrées. Vous définissez d’abord la structure SQL. Ensuite, vous transmettez les valeurs dans des paramètres distincts.
Une saisie contenant des apostrophes reste une simple valeur. Elle ne peut pas modifier la commande. Elle ne peut pas changer l’intention de la requête.
Les paramètres ne conviennent pas directement à certains éléments. Il s’agit notamment :
- des noms de tables
- des noms de colonnes
- du sens d’un tri
Dans ces cas, l’application choisit la valeur dans une liste d’autorisation établie à l’avance.
La validation côté serveur complète cette protection. Elle vérifie le type, la longueur, le format et la plage d’une donnée. Elle ne remplace pas la paramétrisation. Certains champs légitimes doivent accepter des caractères spéciaux.
L’échappement systématique des caractères paraît simple. Pourtant, il dépend du moteur SQL et du contexte. Il reste fragile face aux erreurs d’implémentation et aux requêtes complexes.
Une couche d’abstraction comme un ORM facilite l’usage des paramètres. Elle ne garantit pas la sécurité à elle seule.
Le compte de base de données doit appliquer le principe du moindre privilège. Il ne reçoit que les droits nécessaires à l’application. Il n’a aucun accès administrateur inutile et peut être limité à certaines tables ou procédures.
Le WAF Cloudflare permet d’isoler la règle responsable d’un faux positif
Un WAF, ou pare-feu applicatif web, se place devant votre application. Il examine les requêtes HTTP et bloque les attaques connues. Cloudflare propose des règles gérées contre les injections SQL et d’autres failles web.
Ces règles sont mises à jour régulièrement. Elles peuvent combiner plusieurs correspondances pour évaluer une requête. Avec le jeu de règles fondé sur les recommandations de l’OWASP, plusieurs alertes peuvent s’additionner. Au-delà d’un seuil, la requête est bloquée.
Dans le tableau Security Events, vous filtrez les demandes bloquées ou signalées. Vous pouvez filtrer par Ray ID, par adresse IP ou par période. Vous identifiez ensuite le produit de sécurité et la règle qui ont agi.
Si la journalisation le permet, l’enregistrement détaillé montre la partie de la requête qui a déclenché la règle. Cloudflare propose aussi une journalisation de charge utile chiffrée. Elle confirme le motif détecté.
Vous disposez de deux solutions pour corriger la règle responsable :
- créer une exception ciblée, limitée à une URL ou à un type de requête
- ajuster la règle concernée
- restreindre l’exception à une adresse IP de confiance ou à un paramètre précis
Désactiver l’ensemble du WAF fait disparaître le blocage. Mais cela supprime aussi des protections utiles contre d’autres attaques. Modifiez plutôt une règle individuelle ou un périmètre étroit. Vérifiez d’abord dans les événements de sécurité.
Pour retrouver un blocage de type 1020, recherchez le Ray ID dans Analytics, puis dans l’onglet Events. Tenez compte de l’heure UTC affichée par Cloudflare. Vous pourrez ensuite corriger la règle responsable ou autoriser légitimement l’accès.
Une fois le blocage levé, la défense la plus fiable reste le code lui-même. Pour sécuriser durablement votre application, vérifiez que chaque requête est paramétrée et que le compte de base de données ne reçoit que les droits nécessaires à l’application.