# Protéger les simulateurs d’un courtier derrière un pare-feu applicatif

> Sécuriser des formulaires de simulation de devis sensibles sans introduire de latence perceptible par le visiteur.

- Auteur : Clément Hadrot
- Publié le : 2025-09-22
- Mis à jour le : 2025-09-22
- Catégorie : Hébergement & serveurs
- URL : https://wpmoderne.dev.wordpress-developpement.fr/hebergement/proteger-simulateurs-courtier-pare-feu-applicatif/

## L’essentiel

- Un simulateur de devis expose plus de surface d'attaque qu'une page vitrine
- Le WAF doit filtrer sans jamais bloquer les vraies requêtes
- Chaque règle ajoutée se teste isolément avant activation

`curl -w "%{time_total}\n" -o /dev/null -s https://simulateur.exemple.fr/devis/` : cette simple commande, exécutée avant et après l'activation d'un pare-feu applicatif, permet de vérifier objectivement ce que la plupart des équipes redoutent le plus au moment de sécuriser un formulaire sensible : que la protection ralentisse le service au point de faire fuir le visiteur avant qu'il ait rempli sa simulation.

Un courtier qui propose des simulateurs de devis en ligne manipule des données personnelles sensibles à chaque soumission : revenus, situation familiale, antécédents. Ces formulaires constituent une cible naturelle pour le scraping automatisé, l'injection de données malformées et les tentatives répétées d'extraction de tarifs concurrentiels par des robots.

## Ce qu'un simulateur expose de plus qu'une page vitrine

Un formulaire de simulation reçoit des données en POST à chaque étape, souvent réparties sur plusieurs écrans successifs enregistrés en session. Cette architecture multiplie les points d'entrée par rapport à un site vitrine classique, et chacun de ces points doit accepter des données variées, ce qui rend les règles génériques de filtrage moins efficaces qu'ailleurs.

## Où placer le pare-feu applicatif

Deux positions sont possibles : en amont, au niveau du CDN ou du reverse proxy, ou directement sur le serveur via un module comme `mod_security` pour Apache ou son équivalent pour Nginx. La position en amont présente l'avantage de filtrer avant que la requête n'atteigne PHP-FPM, ce qui protège aussi contre la simple saturation de ressources par des requêtes malveillantes répétées.

```
location /devis/ {
    modsecurity on;
    modsecurity_rules_file /etc/nginx/modsec/simulateur.conf;
    proxy_pass http://127.0.0.1:9000;
}
```

> L'essentiel à retenir : Un simulateur de devis expose plus de surface d'attaque qu'une page vitrine ; Le WAF doit filtrer sans jamais bloquer les vraies requêtes ; Chaque règle ajoutée se teste isolément avant activation

## Écrire des règles qui ciblent, pas qui bloquent tout

La tentation, face à un formulaire sensible, consiste à activer un jeu de règles générique très strict, de type OWASP Core Rule Set en mode bloquant intégral. Sur un simulateur qui accepte des champs de texte libre pour des observations, ce mode bloque régulièrement des soumissions légitimes contenant des caractères interprétés à tort comme des tentatives d'injection.

La démarche qui fonctionne consiste à activer d'abord le jeu de règles en mode détection seule, à observer les faux positifs sur plusieurs jours de trafic réel, puis à ajuster :

```
SecRuleEngine DetectionOnly
SecAuditLog /var/log/modsec_audit.log
```

Une fois les faux positifs identifiés et exclus explicitement par identifiant de règle, le passage en mode bloquant devient beaucoup plus sûr :

```
SecRuleEngine On
SecRuleRemoveById 942100
```

### Limiter le débit sans pénaliser un vrai visiteur

Le scraping de tarifs se repère souvent à la cadence des requêtes plutôt qu'à leur contenu : un visiteur humain ne complète pas dix simulations différentes en quelques secondes. Une limitation de débit par adresse IP, appliquée spécifiquement sur les points d'entrée du simulateur, complète efficacement le filtrage de contenu :

```
limit_req_zone $binary_remote_addr zone=simulateur:10m rate=5r/m;

location /devis/etape-suivante/ {
    limit_req zone=simulateur burst=3 nodelay;
}
```

## Mesurer l'impact avant de généraliser

Chaque règle ajoutée mérite d'être testée isolément, sur un environnement de préproduction identique à la production, avant d'être déployée. L'objectif n'est pas seulement de vérifier qu'elle bloque bien le trafic malveillant simulé, mais aussi de confirmer, chronomètre en main, qu'elle n'introduit pas de latence perceptible sur le parcours réel du visiteur.

> Une règle de prudence qui vaut sur tous les projets sensibles : jamais deux modifications de pare-feu déployées le même jour, pour pouvoir toujours identifier laquelle a provoqué un effet de bord.

## En résumé

Sécuriser un simulateur de devis derrière un pare-feu applicatif ne consiste pas à empiler des règles génériques, mais à construire un jeu de règles ciblé, validé en mode détection avant activation, et complété par une limitation de débit adaptée au rythme réel d'un utilisateur humain. La latence ajoutée, mesurée correctement, reste alors imperceptible pour le visiteur qui remplit sa simulation.