Anfragegrößen begrenzen: Body‑Parsing härten, um DoS‑Angriffe zu verhindern

Warum übergroße Anfragen zum echten Problem werden

Übergroße Anfragen wirken oft harmlos, bis sie eine App lahmlegen. Ein einziger großer Upload, ein riesiges JSON‑Blob oder eine Anfrage, die in einer Retry‑Schleife steckt, kann Speicher und CPU auffressen, andere Nutzer verlangsamen und mitunter den Server zum Absturz bringen.

Ein paar einfache Begriffe helfen:

• Payload: die Daten, die ein Client sendet.
• Body: wo diese Daten normalerweise im HTTP‑Request liegen (z. B. JSON oder eine Datei).
• Parser: der Code (oder die Bibliothek), die den Body liest und in etwas verwandelt, das Ihre App nutzen kann, etwa ein Objekt, einen String oder eine gespeicherte Datei.

Das Risiko sind nicht nur "böse Akteure". Viele Vorfälle sind unbeabsichtigt: ein Mobilfehler, der eine 50‑MB‑Anfrage sendet, ein Frontend, das ein Bild base64‑kodiert in JSON packt, oder eine Integration, die Felder immer weiter anhängt, bis der Body massiv wird. Das Ergebnis kann wie ein Denial‑of‑Service aussehen, selbst wenn niemand es böse meint.

Natürlich ist dieselbe Schwäche auch leicht missbrauchbar. Wenn Ihr Server unbegrenzte Bodies akzeptiert, kann ein Angreifer sehr große Anfragen (oder viele mittelgroße) senden und teure Parsing‑Arbeit erzwingen. Das kann Ihrer App Speicher entziehen, Festplatten füllen und legitimen Traffic blockieren.

Anfragegrößen‑Limits sind wichtig, aber sie sind kein "einmal einstellen und vergessen". Zu geringe Limits brechen echte Nutzer (besonders bei Uploads). Zu hohe Limits erlauben weiterhin Speicher‑Spitzen. Ziel ist ein sicherer Default und klare Ausnahmen für die wenigen Endpunkte, die wirklich größere Bodies brauchen.

Was schiefgehen kann, wenn Sie große Payloads akzeptieren

„Was der Client schickt“ ungefiltert zu akzeptieren, ist ein schneller Weg, einen Endpunkt in einen Ausfall zu verwandeln. Ohne Limits kann ein einziger übergroßer POST Ihre App in hohen Speicherverbrauch, lange Antwortzeiten und kaskadierende Fehler treiben.

Der erste Schlag trifft oft den Speicher. Viele Frameworks puffern den gesamten Body, bevor Ihr Handler ausgeführt wird. Ein großes JSON‑Payload oder ein multipart Upload kann außerdem während Pufferns, Decodierens und Validierens mehrfach kopiert werden. Das vervielfacht die Speicherkosten, und es braucht nicht viele parallele Anfragen, um einen Container oder VM auszureizen.

CPU ist das nächste Problem. Riesiges JSON zu parsen kostet Zeit, und tief verschachtelte Objekte können das verschlimmern. Selbst wenn die Nutzlast „gültig“ ist, kann der Server Sekunden damit verbringen, Bytes in Objekte zu verwandeln, sodass weniger CPU für echte Arbeit bleibt. Manche Parser machen bei großen Eingaben zusätzliche Arbeit (Coercion, Validierung), was die Kosten pro Anfrage erhöht.

Übergroße Bodies binden außerdem Worker. Ein langsamer Upload hält eine Verbindung offen, bindet einen Worker‑Thread oder das Event‑Loop und schiebt andere Nutzer in Timeouts. Unter Last stapeln sich Retries und potenzieren den Schaden.

Uploads können auch stillschweigend die Festplatte treffen. Wenn temporäre Dateien am falschen Ort landen (oder nie bereinigt werden), kann ein Schub großer Anfragen die Festplatte füllen und unbeteiligte Teile der App zum Absturz bringen.

Teams unterschätzen oft die „sekundären“ Kosten: Bandbreitenspitzen und Cloud‑Rechnungen (besonders bei Retries), langsamere Hintergrund‑Queues wegen CPU‑ und Speicherbelastung, laute Logs und blinde Flecken, weil einige Fehler auftreten, bevor App‑Code läuft. Ein weiterer häufiger Fehler ist, Authentifizierung nach dem Parsen zu prüfen — das macht Missbrauch billiger.

Ein realistisches Szenario: Ein Signup‑Endpoint akzeptiert JSON mit einem Feld „profile“. Ein fehlerhafter Client sendet einen 50‑MB‑Blob. Der Server puffert, parst und blockiert. Kommen ein paar weitere parallel dazu, wird der Dienst unbrauchbar.

Wo Limits durchgesetzt werden sollten, damit sie wirken

Zuverlässige Limits werden auf mehr als einer Ebene durchgesetzt. Wenn Sie nur im App‑Code ein Limit setzen, kann der Server trotzdem Zeit und Speicher damit verbringen, einen riesigen Body zu lesen, bevor Ihr Code ihn ablehnt. Wenn Sie nur am Edge begrenzen, möchten Sie trotzdem engere Kontrollen für bestimmte Endpunkte.

1) Edge‑Layer: Stoppen Sie übergroße Anfragen, bevor sie Ihre App erreichen

Ihre erste Schutzschicht sollte die Stelle sein, die Traffic zuerst empfängt, z. B. CDN, Load Balancer, Reverse Proxy oder API‑Gateway. Hier können Sie übergroße Bodies früh ablehnen, ein HTTP 413 zurückgeben und vermeiden, App‑Worker zu blockieren. Das hilft auch gegen langsame, übergroße Uploads, die darauf abzielen, Verbindungen offen zu halten.

Halten Sie das Edge‑Limit strikt für allgemeinen Traffic. Wenn Sie größere Uploads benötigen, handhaben Sie diese über einen separaten Pfad oder Service, anstatt das Limit für alles anzuheben.

2) App‑Layer: Endpoint‑spezifische Limits und sichere Defaults

Innerhalb der App setzen Sie Limits erneut, sodass jeder Endpoint die richtige Obergrenze hat. Ein Login‑Endpoint sollte nur kleine JSON‑Bodies akzeptieren. Ein Profilfoto‑Endpoint darf mehr erlauben.

Ein praktisches Muster ist ein kleines globales Max‑Body‑Size für die meisten API‑Routen mit Per‑Route‑Caps für Ausnahmen. Öffentliche Endpunkte sollten strenger sein als authentifizierte. Lehnen Sie früh ab, wenn möglich (Prüfen von Content-Length, wenn vorhanden), und nutzen Sie Timeouts für das Lesen des Bodys, nicht nur für die Verarbeitung.

Uploads verdienen besondere Behandlung. Behandeln Sie Datei‑Uploads als anderen Flow als normale JSON‑APIs, denn Uploads können große Speicher‑Spitzen auslösen, wenn ein Parser alles puffert. Bevorzugen Sie Streaming oder Chunked‑Handling, schreiben Sie direkt auf die Festplatte oder in Object Storage und validieren Sie Dateityp und Größe, bevor Sie teure Arbeit ausführen.

Wie Sie sichere Payload‑Limits wählen, ohne Nutzer zu brechen

Listen Sie zuerst jeden Endpoint auf, der einen Request‑Body akzeptiert. Limits sind nur sicher, wenn sie zur realen Nutzung passen. Der schnellste Weg ist, ein Inventar dessen zu erstellen, was Sie tatsächlich akzeptieren – nicht was Sie annehmen, zu akzeptieren.

Gruppieren Sie Endpunkte nach dem, was sie empfangen sollen. JSON‑APIs brauchen normalerweise die kleinsten Limits. Form‑Posts liegen oft im Mittelfeld. Datei‑Uploads benötigen größere Limits. Webhooks können mit gelegentlichen großen Bursts überraschen.

Ein praktischer Ausgangspunkt ist, enge Defaults zu setzen und Limits nur bei klarer Notwendigkeit anzuheben. Zum Beispiel:

• JSON‑API‑Endpoints: 16 KB bis 256 KB
• Form‑Posts (ohne Dateien): 64 KB bis 512 KB
• Datei‑Uploads: 5 MB bis 25 MB (nur auf bestimmten Routen)
• Webhooks: 256 KB bis 2 MB (abhängig von Provider‑Docs und Logs)

Diese Zahlen sind nicht universal, aber das Muster ist wichtig: Die meisten Routen sollten klein sein, und nur wenige sollten groß sein dürfen.

Berücksichtigen Sie, dass Sie mehr begrenzen als „nur Nutzerdaten“. Header, Cookies und multipart‑Boundary fügen Overhead hinzu. Base64 bläht Inhalte um etwa ein Drittel auf. Ein 2‑MB‑Bild in JSON kann vor der Verarbeitung näher an 2,7 MB ankommen.

Planen Sie Ausnahmen explizit. Wenn ein Endpoint wirklich 25 MB braucht, geben Sie nur dieser Route 25 MB und halten Sie den Default niedrig, anstatt der gesamten App unendlich viel Platz zu geben. Dokumentieren Sie, wer die Ausnahme nutzt, was gesendet wird und was eine vernünftige Obergrenze ist.

Ein häufiger Geruch ist ein einziger generischer Endpoint (z. B. "/api/save"), der alles akzeptiert. Das Aufteilen in einen kleinen JSON‑Endpoint und einen separaten Upload‑Endpoint stoppt oft plötzliche Speicher‑Spitzen, ohne normale Nutzer zu stören.

Body‑Parsing‑Regeln, die Speicher‑ und CPU‑Spitzen reduzieren

Der schnellste Weg, Speicher‑ und CPU‑Spitzen zu triggern, ist, Ihre App raten zu lassen, was ein Request‑Body enthält, und ihn dann automatisch zu parsen. Hardening des Body‑Parsings bedeutet streng zu sein: Akzeptieren Sie nur, was Sie erwarten, und parsen Sie nur, wenn es wirklich nötig ist.

Beginnen Sie mit einer Allowlist von Content‑Types pro Endpoint. Wenn ein Endpoint JSON erwartet, akzeptieren Sie nur application/json (und die genauen Varianten, die Sie unterstützen). Wenn Content‑Type fehlt oder unbekannt ist, lehnen Sie früh ab. Das verhindert versehentliches Parsen riesiger Text‑Payloads, merkwürdiger Encodings oder Eingaben, die Ihren Parser übermäßig arbeiten lassen.

Guardrails fürs JSON‑Parsing

Falls Ihr Framework es unterstützt, begrenzen Sie die JSON‑Komplexität, nicht nur die Größe. Eine kleine Anfrage kann trotzdem teuer sein, wenn sie tief verschachtelt ist oder tausende Keys enthält.

Gute Defaults zum Erwägen:

• Maximale JSON‑Tiefe (z. B. 20 bis 50 Ebenen)
• Maximale Feldanzahl (z. B. 1.000 bis 10.000 Keys)
• Maximale String‑Länge für einzelne Felder (z. B. 10 KB bis 100 KB)
• Striktes UTF‑8‑Handling (ungültige Sequenzen ablehnen)
• Schnelles Fehlschlagen bei doppelten Keys (wenn unterstützt)

Deaktivieren Sie automatisches Parsen auf Routen, die es nicht brauchen. Viele Apps parsen JSON global für jede Anfrage, einschließlich Health‑Checks, Webhook‑Verifizierungsendpunkte und simpler GET‑Routen. Das ist verschwendete Arbeit und ein leichtes Ziel.

Bei Uploads: Bevorzugen Sie Streaming (Chunk‑Verarbeitung) statt das komplette File vorab in den Speicher zu lesen. Kombinieren Sie Streaming mit Größenlimits, damit eine einzelne Anfrage den RAM nicht füllen kann.

Beispiel: Ein Signup‑Endpoint erwartet eine kleine JSON. Wenn der Server jeden Content‑Type akzeptiert und automatisch parst, kann ein Angreifer ein mehrere Megabyte großes Payload mit einer komplizierten Struktur senden, das die CPU in Anspruch nimmt. Strenge Content‑Type‑Regeln plus Tiefe‑ und Feldlimits führen stattdessen zu einer schnellen Ablehnung statt zu einem Ausfall.

Schritt für Schritt: Limits und Parsing härten

Die meisten Ausfälle durch übergroße Anfragen treffen leicht erreichbare Endpunkte: öffentliche Formulare, unauthentifizierte APIs und Webhooks. Beginnen Sie damit, jede Route, die einen Body akzeptiert, aufzulisten, und markieren Sie, welche öffentlich, welche von Dritten aufgerufen und welche Dateien akzeptieren.

Eine praktische Checkliste

Starten Sie am Edge (Load Balancer, Reverse Proxy, CDN oder API‑Gateway). Edge‑Kontrollen sind die erste Verteidigungslinie, weil sie die Anfrage blockieren, bevor Ihre App Speicher zum Parsen verwendet.

• Identifizieren Sie risikoreiche Endpunkte (öffentlich, unauthentifiziert, Webhooks, Uploads).
• Setzen Sie Edge‑Caps: maximale Body‑Größe, maximale Header‑Größe und kurze Read‑Timeouts.
• Fügen Sie Pfad‑Ausnahmen nur hinzu, wenn Sie sie begründen können (z. B. eine Upload‑Route).
• Stellen Sie sicher, dass das Edge für übergroße Requests HTTP 413 zurückgibt.
• Vergewissern Sie sich, dass das Limit tatsächlich durchgesetzt wird (manche Stacks puffern, bevor sie ablehnen).

Dann härten Sie die App. App‑seitige Limits schützen, wenn Traffic das Edge umgeht (interne Calls, Fehlkonfiguration) und erlauben feinere Regeln als ein einziger globaler Grenzwert.

• Wenden Sie pro Route und pro Content‑Type Request‑Size‑Limits an (JSON vs multipart Upload).
• Setzen Sie Parser‑Defaults: max JSON‑Größe, maximale Tiefe und striktes Parsen (ungültiges JSON ablehnen; doppelte Keys ablehnen, falls möglich).
• Vermeiden Sie parsen in den Speicher, wenn möglich: streamen Sie Uploads und validieren Sie Typ und Größe früh.
• Testen Sie normale und bewusst übergroße Requests, inklusive komprimierter Bodies, falls Sie diese akzeptieren.
• Beobachten Sie Logs für 413s und Read‑Timeouts für eine Woche und passen Sie nur bei nachgewiesenem Bedarf an.

Ein realer Fall: Ein Webhook‑Endpoint akzeptierte JSON ohne Cap. Eine einzige übergroße Nutzlast konnte Speicher spike und den Dienst neu starten. Ein kleines per‑Route‑JSON‑Limit an der Webhook‑Route verhinderte die Spitze, ohne normalen Traffic zu stören.

Sichere und benutzerfreundliche Fehlerbehandlung

Wenn Sie Limits durchsetzen, stellt sich die Frage: Was sieht der Client, wenn er die Grenze überschreitet? Gute Fehlerbehandlung stoppt den Angriff (oder Unfall) früh, sagt aber echten Nutzern, wie sie das Problem beheben.

Verwenden Sie Statuscodes, die zum Problem passen. Eine zu große Nutzlast sollte 413 Payload Too Large zurückgeben. Ein Body, den Sie nicht akzeptieren (z. B. XML an einem JSON‑Only‑Endpoint), sollte 415 Unsupported Media Type zurückgeben. Bei einer fehlerhaften Anfrage ist 400 Bad Request meist ausreichend. Passende Fehler verhindern blinde Retries.

Hal­ten Sie Fehlermeldungen kurz und praktisch. Sagen Sie, was zu ändern ist: „Datei zu groß. Max 10 MB.“ oder „Nur application/json wird unterstützt.“ Geben Sie nicht den Request‑Body, Header oder Benutzereingaben in der Antwort zurück — so reduzieren Sie das Risiko, Geheimnisse zu leaken.

Beim Logging möchten Sie genug Kontext zum Debuggen, ohne die abgelehnte Nutzlast zu speichern. Ein guter Mittelweg ist, Endpoint und Methode, Statuscode (413, 415), beobachtete Content‑Length (falls angegeben) und das konfigurierte Limit, Content‑Type sowie eine Request‑ID und Benutzer-/Account‑ID (wenn bekannt) zu protokollieren.

Entscheiden Sie pro Endpoint, wo früh abgebrochen wird. Bei öffentlichen Upload‑Endpoints und Auth‑Routes spart das Edge Arbeit. Bei Endpunkten, deren Limits routenabhängig sind, muss die App entscheiden, aber sie sollte trotzdem vor dem vollständigen Parsen ablehnen.

Häufige Fehler, die zu Ausfällen oder leichtem DoS führen

Die meisten Ausfälle durch übergroße Anfragen passieren nicht, weil gar keine Limits existieren, sondern weil Limits uneinheitlich sind, umgangen werden oder zu spät greifen. Ein häufiges Muster ist, ein einziges globales Limit zu setzen und zu glauben, damit sei alles erledigt. Dann erlaubt eine Upload‑Route, ein Webhook oder eine Reverse‑Proxy‑Ausnahme deutlich größere Bodies. Angreifer müssen nicht Ihr Haupt‑API treffen — sie finden eine schwache Stelle.

Wiederkehrende Fehler:

• JSON‑Bodies limitieren, aber Datei‑Uploads und Webhooks vergessen (oder eine eigene Stufe auf „unbegrenzt“ setzen).
• Limits „nur für heute“ erhöhen, um einen Client zu befreien, und nie wieder zurücksetzen.
• Zuerst parsen und erst danach die Größe prüfen. Wenn Sie erst später ablehnen, haben Sie schon Speicher und CPU verbraucht.
• Jeden Content‑Type akzeptieren und Bibliotheken raten lassen, wie geparst werden soll; das kann langsame Parsing‑Pfade oder unerwartete Dekompression auslösen.
• Base64‑Dateien in JSON erlauben ohne strikte Caps, sodass eine „10 MB‑Datei“ auf dem Weg und im Speicher stark aufbläht.

Ein weiterer Stolperstein ist, echte Nutzer zu blockieren, weil Limits nie getestet wurden. Mobile Clients können größere Header senden, Partner‑Webhooks ausführliche Metadaten enthalten. Wenn Sie eine Zahl raten und ausliefern, lernen Sie das während einer Stoßzeit.

Besser ist es, Limits mit Ihren echten Clients zu testen, bevor Sie sie strikt durchsetzen. Sammeln Sie repräsentative Payloads (klein, typisch, Worst‑Case), setzen Sie Limits mit etwas Puffer und halten Sie Fehlermeldungen klar.

Schnelle Checks, die Sie in 15 Minuten machen können

Sie brauchen kein großes Sicherheitsprojekt, um das Risiko schnell zu reduzieren. Ein kurzer Check von Anfrage‑Limits und Parsing‑Einstellungen kann Speicher‑Spitzen und einfache Denial‑of‑Service‑Versuche verhindern.

Der 15‑Minuten‑Setup‑Check

Starten Sie am Edge (Load Balancer, CDN, Reverse Proxy). Wenn dort riesige Bodies akzeptiert werden, bekommt Ihre App nie die Chance, sich zu schützen. Gehen Sie dann in Ihre App‑Routen.

• Bestätigen Sie, dass es am Edge ein hartes Body‑Size‑Cap gibt und dass es tatsächlich durchgesetzt wird (testen Sie mit einer übergroßen Anfrage).
• Wählen Sie 3–5 Endpunkte, die Bodies akzeptieren, und notieren Sie ihre vorgesehenen Max‑Größen.
• Fügen Sie eine einfache Content‑Type‑Allowlist für Body‑Endpoints hinzu.
• Prüfen Sie Ihre JSON‑Parser‑Einstellungen auf ein Max‑Size‑Limit und begrenzen Sie Tiefe oder Komplexität, falls Ihr Framework das unterstützt.
• Bei Datei‑Uploads vermeiden Sie das komplette Puffern im Speicher. Nutzen Sie Streaming oder einen dedizierten Upload‑Flow.

Der 5‑Minuten‑Failure‑Test

Stellen Sie sicher, dass die App sicher und vorhersehbar fehlschlägt. Sie wollen eine klare, konsistente Antwort, die in Logs und Monitoring sichtbar ist.

Testen Sie end‑to‑end:

• HTTP 413, wenn die Nutzlast zu groß ist (und die Verbindung ordentlich geschlossen wird).
• HTTP 415, wenn der Content‑Type nicht erlaubt ist.
• Timeouts, die langsame, nie endende Uploads abschneiden.
• Dass eine laute IP nicht wiederholt teure Parsing‑Arbeit auslösen kann.

Beispiel: Einen realen Speicher‑Spike von einem Endpoint stoppen

Ein öffentlicher Signup‑Endpoint sah im Test gut aus, begann aber bei Traffic‑Spitzen zu timeouts. CPU und Speicher stiegen, und die App startete alle paar Minuten neu. Es sah aus wie „zu viele Nutzer“, aber die Logs zeigten: Nur wenige Requests dauerten deutlich länger als der Rest.

Die Ursache war die Form der Payload, nicht nur die Menge. Angreifer (und ein paar fehlerhafte Clients) schickten übergroße JSON‑Bodies und tief verschachtelte Objekte. Selbst wenn die Anfrage später durch Validierung abgelehnt wurde, hatte der Server schon Zeit und Speicher für das Lesen und Parsen investiert. Eine Handvoll solcher Anfragen konnte die Laufzeit in intensive Garbage‑Collection treiben und dann zu OOMs führen.

Die Lösung war einfach: Limits und strengere Parsing‑Regeln vor der Applikationslogik.

Was sich änderte

Wir schränkten den Signup‑Endpoint so ein, dass er nur noch das annimmt, was wirklich gebraucht wird:

• Eine kleine maximale Body‑Größe für JSON‑Requests
• Maximale Verschachtelungstiefe für JSON‑Objekte
• Strenge Content‑Type‑Prüfung (nur JSON)
• Kurze Timeouts für das Lesen des Request‑Bodys
• Klare HTTP 413‑Antworten mit kurzem Fehlertext

Danach verursachte derselbe Traffic‑Spike keine Neustarts mehr. Der Speicher blieb stabil, weil riesige Bodies nie den JSON‑Parser erreichten, und tief verschachtelte Payloads wurden schnell abgelehnt. Auch die Logs wurden sauberer: Statt langer Stacktraces gab es kurze, konsistente Einträge wie „Payload too large“ oder „JSON too deep“. Für echte Nutzer änderte sich kaum etwas; normale Signups funktionierten weiter. Nur fehlerhafte Clients erhielten jetzt eine schnelle, klare Fehlermeldung statt eines endlosen Ladens und eines generischen Timeouts.

Nächste Schritte und wann Sie Hilfe holen sollten

Bevor Sie etwas ändern, machen Sie einen kurzen Snapshot dessen, was Sie schützen. Das hilft, echte Nutzer nicht zu stören und gleichzeitig die einfachsten DoS‑Pfade zu schließen.

Sammeln Sie:

• Eine Liste der Endpunkte, die Request‑Bodies akzeptieren (JSON, Formulare, Uploads)
• Ihre aktuellen Anfragegrößen‑Limits (pro Endpoint und am Proxy/App‑Server)
• Aktuelle Error‑Logs für 413s, Timeouts, Speicher‑Spitzen und langsame Requests
• Hinweise, wer welche Endpunkte nutzt und typische Payload‑Größen
• Alle Hintergrundjobs, die intern große Payloads posten

Rollen Sie Änderungen in der sichersten Reihenfolge aus: öffentliche Routen zuerst, dann Webhook‑Empfänger und danach Endpunkte, die untrusted JSON parsen. Halten Sie Limits auf diesen Routen eng und lockern Sie nur bei klarer Benutzeranforderung und sicherem Parsing‑Weg.

Nach dem Deployment verhindern Sie, dass Limits mit der Zeit wachsen. Bewahren Sie ein paar repräsentative Requests auf (ein normaler, einer nahe am Limit, einer klar übergroß) und führen Sie sie nach jedem Release aus, um schnelle Ablehnung, korrekte HTTP 413‑Behandlung und stabile Speicher‑/CPU‑Werte zu prüfen.

Wenn Sie einen KI‑generierten Codebestand geerbt haben, lohnt sich ein fokussiertes Audit auf riskante Defaults wie unbegrenzte Body‑Parser, Upload‑Endpoints ohne Caps und schwache Input‑Checks. FixMyMess (fixmymess.ai) spezialisiert sich darauf, KI‑generierte Anwendungen zu diagnostizieren und zu reparieren: Limits zu schärfen, Parsing‑Pfade zu korrigieren, die im Speicher puffern, und verwandte Sicherheitsprobleme zu härten. Sie bieten auch ein kostenloses Code‑Audit an, um Probleme zu identifizieren, bevor Sie Änderungen vornehmen.