# WAF pour une application Next.js : les règles managées qui bloquent du trafic légitime, et ce que nous en avons fait
Activer AWS WAF devant une application web, c'est un construct CDK et quelques cases à cocher de groupes de règles managées. C'est aussi, d'après notre expérience, la garantie de bloquer quelque chose de réel dès la première semaine : une soumission de formulaire, un webhook, un envoi d'image, un champ de texte enrichi. Les règles ne sont pas fausses. Elles sont génériques, et votre application ne l'est pas.
Voici la configuration WAF que nous exploitons devant une application Next.js publique sur App Runner, les cinq règles managées qui ont bloqué du trafic légitime, la raison pour laquelle chacune s'est déclenchée, et la surcharge qui a corrigé le problème sans désactiver la règle pour tout.
## La configuration
CloudFront devant, App Runner derrière, WAF attaché à la distribution CloudFront pour qu'il voie chaque requête avant l'origine. Trois groupes de règles managées plus une limite de débit :
```ts
const acl = new wafv2.CfnWebACL(this, 'WebAcl', {
scope: 'CLOUDFRONT',
defaultAction: { allow: {} },
visibilityConfig: { sampledRequestsEnabled: true, cloudWatchMetricsEnabled: true, metricName: 'web-acl' },
rules: [
managedGroup('AWSManagedRulesAmazonIpReputationList', 10),
managedGroup('AWSManagedRulesKnownBadInputsRuleSet', 20),
managedGroup('AWSManagedRulesCommonRuleSet', 30, /* surcharges ci-dessous */),
{
name: 'rate-limit', priority: 40,
statement: { rateBasedStatement: { limit: 2000, aggregateKeyType: 'IP' } },
action: { block: {} },
visibilityConfig: { sampledRequestsEnabled: true, cloudWatchMetricsEnabled: true, metricName: 'rate-limit' },
},
],
});
```
Coût : 5 $ pour la web ACL, 1 $ par groupe de règles, 0,60 $ par million de requêtes. Environ 16 $ par mois chez nous, le contrôle de sécurité le moins cher de la facture après la [politique de protection des données](/fr/blog/cloudwatch-data-protection-policies-pii).
## Compter d'abord, bloquer ensuite
Nous n'avons pas commencé en mode blocage. Chaque groupe managé a tourné avec son action surchargée en `COUNT` pendant deux semaines, le log des requêtes échantillonnées allant vers S3 et un tableau de bord CloudWatch montrant les comptes par règle. C'est cette période qui a produit la liste ci-dessous. Sans elle, nous aurions trouvé chacun de ces cas par un utilisateur signalant un formulaire cassé, ce qui est la façon dont la plupart des équipes les trouvent.
La requête du tableau de bord est simple : nombre de requêtes correspondantes par `terminatingRuleId` et `ruleGroupList[].ruleId`, filtré sur celles avec l'action `COUNT`. Tout ce qui a un volume réel et n'est pas manifestement une attaque est examiné à la main : quel chemin, quel corps, quel client.
## Les cinq règles qui ont bloqué du vrai trafic
Les cinq sont dans `AWSManagedRulesCommonRuleSet`, le groupe que tout le monde active et celui qui a le plus d'opinions sur ce à quoi une requête devrait ressembler.
**1. `SizeRestrictions_BODY` : tout corps de requête au-delà de 8 Ko.** La règle existe parce que les corps surdimensionnés sont un vecteur d'attaque courant et parce que le WAF n'inspecte de toute façon que les 8 premiers Ko (16 Ko sur CloudFront dans les configurations plus récentes). Notre formulaire d'édition de profil envoie une charge JSON avec un avatar en data URL base64. Ça fait 40 Ko. Bloqué. Chaque sauvegarde de profil d'un utilisateur avec une photo, perdue, pendant les deux semaines qu'il aurait fallu à quelqu'un pour le signaler.
*Correctif :* la règle reste en mode blocage globalement et est surchargée en `COUNT` pour les deux routes qui acceptent légitimement de gros corps, via un scope-down statement sur le chemin URI. Meilleur correctif, que nous avons aussi appliqué : les envois vont vers S3 via une URL présignée et le formulaire envoie une clé, pas les octets, donc le corps refait 2 Ko.
**2. `CrossSiteScripting_BODY` : du HTML dans un corps de requête.** Un éditeur de texte enrichi pour les descriptions de produits soumet du HTML assaini. Pour la règle XSS, `