# WAF für eine Next.js-App: die Managed Rules, die legitimen Traffic blockieren, und was wir dagegen getan haben
AWS WAF vor einer Webanwendung einzuschalten ist ein CDK-Construct und eine Handvoll Häkchen bei Managed Rule Groups. Es ist außerdem, nach unserer Erfahrung, garantiert, dass es in der ersten Woche etwas Echtes blockiert: eine Formularübermittlung, einen Webhook, einen Bild-Upload, ein Rich-Text-Feld. Die Regeln sind nicht falsch. Sie sind generisch, und Ihre Anwendung ist es nicht.
Das hier ist die WAF-Konfiguration, die wir vor einer öffentlichen Next.js-Anwendung auf App Runner betreiben, die fünf Managed Rules, die legitimen Traffic blockiert haben, der Grund, warum jede ausgelöst hat, und der Override, der es behoben hat, ohne die Regel für alles abzuschalten.
## Das Setup
CloudFront davor, App Runner dahinter, WAF an die CloudFront-Distribution gehängt, sodass sie jeden Request sieht, bevor die Origin es tut. Drei Managed Rule Groups plus ein Rate-Limit:
```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, /* Overrides unten */),
{
name: 'rate-limit', priority: 40,
statement: { rateBasedStatement: { limit: 2000, aggregateKeyType: 'IP' } },
action: { block: {} },
visibilityConfig: { sampledRequestsEnabled: true, cloudWatchMetricsEnabled: true, metricName: 'rate-limit' },
},
],
});
```
Kosten: $5 für die Web ACL, $1 pro Rule Group, $0,60 pro Million Requests. Etwa $16 im Monat bei uns, die billigste Sicherheitskontrolle auf der Rechnung nach der [Data Protection Policy](/de/blog/cloudwatch-data-protection-policies-pii).
## Erst zählen, später blockieren
Wir haben nicht im Block-Modus angefangen. Jede Managed Group lief zwei Wochen lang mit auf `COUNT` überschriebener Aktion, das Sampled-Request-Log ging nach S3 und ein CloudWatch-Dashboard zeigte Treffer pro Regel. Diese Phase hat die Liste unten hervorgebracht. Ohne sie hätten wir jeden dieser Punkte gefunden, indem ein Nutzer ein kaputtes Formular meldet, und so finden es die meisten Teams.
Die Dashboard-Abfrage ist einfach: Anzahl passender Requests pro `terminatingRuleId` und `ruleGroupList[].ruleId`, gefiltert auf die mit Aktion `COUNT`. Alles mit echtem Volumen, das nicht offensichtlich ein Angriff ist, wird von Hand geprüft: welcher Pfad, welcher Body, welcher Client.
## Die fünf Regeln, die echten Traffic blockiert haben
Alle fünf stehen im `AWSManagedRulesCommonRuleSet`, der Gruppe, die alle einschalten und die die meisten Meinungen darüber hat, wie ein Request auszusehen hat.
**1. `SizeRestrictions_BODY`: jeder Request-Body über 8 KB.** Die Regel existiert, weil übergroße Bodies ein häufiger Angriffsvektor sind und weil WAF ohnehin nur die ersten 8 KB inspiziert (16 KB auf CloudFront in neueren Konfigurationen). Unser Profil-Bearbeitungsformular sendet einen JSON-Payload mit einem Avatar als Base64-Data-URL. Das sind 40 KB. Blockiert. Jedes Speichern eines Profils mit Foto, weg, für die zwei Wochen, die es gedauert hätte, bis jemand es meldet.
*Fix:* Die Regel bleibt global im Block-Modus und wird per Scope-Down-Statement auf dem URI-Pfad für die zwei Routen, die legitim große Bodies annehmen, auf `COUNT` überschrieben. Bessere Lösung, die wir ebenfalls umgesetzt haben: Uploads gehen per Presigned URL nach S3, und das Formular sendet einen Schlüssel, nicht die Bytes, sodass der Body wieder 2 KB hat.
**2. `CrossSiteScripting_BODY`: HTML in einem Request-Body.** Ein Rich-Text-Editor für Produktbeschreibungen sendet bereinigtes HTML. Für die XSS-Regel sind `