# WAF pentru o aplicație Next.js: regulile managed care blochează trafic legitim, și ce am făcut cu ele
Să pornești AWS WAF în fața unei aplicații web e un construct CDK și o bifă de grupuri de reguli managed. E și, din experiența noastră, garantat să blocheze ceva real în prima săptămână: o trimitere de formular, un webhook, un upload de imagine, un câmp de text formatat. Regulile nu greșesc. Sunt generice, iar aplicația ta nu e.
Asta e configurația de WAF pe care o rulăm în fața unei aplicații Next.js publice pe App Runner, cele cinci reguli managed care au blocat trafic legitim, motivul pentru care s-a declanșat fiecare și override-ul care a rezolvat fără să oprim regula pentru tot.
## Configurația
CloudFront în față, App Runner în spate, WAF atașat distribuției CloudFront, ca să vadă fiecare request înaintea originii. Trei grupuri de reguli managed plus o limită de rată:
```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, /* override-uri mai jos */),
{
name: 'rate-limit', priority: 40,
statement: { rateBasedStatement: { limit: 2000, aggregateKeyType: 'IP' } },
action: { block: {} },
visibilityConfig: { sampledRequestsEnabled: true, cloudWatchMetricsEnabled: true, metricName: 'rate-limit' },
},
],
});
```
Cost: $5 pentru web ACL, $1 per grup de reguli, $0,60 per milion de request-uri. Cam $16 pe lună la noi, cel mai ieftin control de securitate de pe factură după [politica de protecție a datelor](/ro/blog/cloudwatch-data-protection-policies-pii).
## Întâi numeri, apoi blochezi
N-am început în modul block. Fiecare grup managed a rulat cu acțiunea suprascrisă pe `COUNT` timp de două săptămâni, cu logul de request-uri eșantionate mergând în S3 și un dashboard CloudWatch cu numărul de potriviri per regulă. Perioada aia a produs lista de mai jos. Fără ea, am fi găsit fiecare dintre ele printr-un utilizator care raportează un formular stricat, adică felul în care le găsesc majoritatea echipelor.
Query-ul de dashboard e simplu: numărul de request-uri potrivite per `terminatingRuleId` și `ruleGroupList[].ruleId`, filtrat pe cele cu acțiunea `COUNT`. Orice are volum real și nu e evident un atac e examinat de mână: ce cale, ce body, ce client.
## Cele cinci reguli care au blocat trafic real
Toate cinci sunt în `AWSManagedRulesCommonRuleSet`, grupul pe care îl activează toată lumea și cel cu cele mai multe opinii despre cum ar trebui să arate un request.
**1. `SizeRestrictions_BODY`: orice body de request peste 8 KB.** Regula există pentru că body-urile supradimensionate sunt un vector de atac comun și pentru că WAF inspectează oricum doar primii 8 KB (16 KB pe CloudFront în configurațiile mai noi). Formularul nostru de editare a profilului trimite un payload JSON cu un avatar ca data URL base64. Adică 40 KB. Blocat. Fiecare salvare de profil de la un utilizator cu poză, dispărută, pentru cele două săptămâni cât i-ar fi luat cuiva s-o raporteze.
*Rezolvare:* regula rămâne în modul block global și e suprascrisă pe `COUNT` pentru cele două rute care acceptă legitim body-uri mari, printr-un scope-down statement pe calea URI. Rezolvarea mai bună, pe care am făcut-o și noi: upload-urile merg în S3 printr-un presigned URL, iar formularul trimite o cheie, nu octeții, deci body-ul e din nou 2 KB.
**2. `CrossSiteScripting_BODY`: HTML într-un body de request.** Un editor de text formatat pentru descrieri de produse trimite HTML sanitizat. Pentru regula XSS, `