Body Parsing und Validation in Bun.js: JSON, Uploads, Streams und Payload Limits
Ein praktischer Deep Dive zu Body Parsing Middleware in Bun.js: JSON, FormData, Uploads, Streams, Payload Limits, Schema Validation, Idempotency, Content-Type Checks, sichere Middleware-Reihenfolge und schlechte Praktiken.
Bun.js Middleware Production Guide 2026
Eine Serie über Production Middleware in Bun.js: Überblick, Security, Performance, Observability, Rate Limiting, Body Parsing, WebSocket/SSE und Tests für die Request Pipeline.
Alle Artikel in diesem Guide
01
Bun.js Middleware 2026: Overview, Best Practices und Anti-Patterns
Das grundlegende mentale Modell für Middleware in nativem Bun, Hono und Elysia, mit Beispielen, Optimierung und Roadmap für die nächsten Deep-Dive-Artikel.
02
Auth Middleware in Bun.js: JWT, Sessions, API Keys und Multi-Tenant Context
Wie man Auth Middleware in Bun richtig baut: Reihenfolge der Prüfungen, Cache, Token Rotation, Tenant Context, 401/403-Fehler und Tests.
03
Rate Limiting in Bun.js: in-memory, Redis, Sliding Window und Edge Cases
Ein detaillierter Blick auf Rate Limiting für Bun APIs: Algorithmen, Redis, distributed limits, abuse protection und graceful degradation.
04
Observability Middleware in Bun.js: Logs, Request ID, Tracing und Latency Budgets
Wie man request id, structured logs, timing headers, einen OpenTelemetry-ähnlichen Flow hinzufügt und Logging nicht zum Bottleneck macht.
05
Body Parsing und Validation in Bun.js: JSON, Uploads, Streams und Payload Limits
Wie man Request Bodies in Bun sicher liest, wo Limits hingehören und wie man Streams, Uploads, Idempotency und Schema Validation nicht kaputtmacht.
In Bun, wie im Web API Modell generell, ist der Request Body keine unendliche Variable, die man beliebig oft lesen kann. Er ist ein Stream. Wenn eine Schicht ihn ohne Contract mit dem Rest der Pipeline liest, kann die nächste Schicht einen leeren Body, einen Fehler oder unerwartetes Verhalten bekommen.
Genau deshalb sollte Body Parsing nicht „für alle Fälle“ in globaler Middleware versteckt werden. Es muss route-aware, content-type aware und size-aware sein.
In diesem Artikel zeigen wir, wie Parsing und Validation so gebaut werden, dass sie die API schützen, statt Memory Pressure, Security Holes und merkwürdige Bugs zu erzeugen.
karte
Das ist das finale Chapter der aktuellen Bun Middleware Roadmap. Es schließt das Thema Request Body ab, eine der häufigsten Quellen für Memory-, Security- und Validation-Probleme in APIs.
req.json(), Body Logs, Parsing nach Auth/Rate Limit in falscher Reihenfolge, Validation ohne strip/strict policy.Die wichtigste Regel: Der Request Body sollte genau einen Owner haben. Wenn mehrere Middleware-Schichten versuchen, den Body selbstständig zu lesen, wird die Pipeline fragil.
Route und Method prüfen
Lies den Body nicht für GET/HEAD oder Routes, die keinen Body brauchen. Das spart Latency und entfernt zufällige Side Effects.
Content-Type prüfen
Eine JSON Route sollte application/json akzeptieren, eine Upload Route multipart/form-data oder einen konkreten binary content-type. Parse nicht alles als JSON.
Size Limit anwenden
Wenn das Limit erst nach await req.json() oder await req.formData() geprüft wird, schützt es den Speicher nicht mehr vor einem großen Payload.
Body einmal lesen
Nutze json(), formData(), arrayBuffer() oder einen Stream abhängig von der Route. Gib den parsed value in den Context.
Validieren und typed value weitergeben
Schema Validation sollte ein typisiertes Ergebnis oder ein stabiles 400/422 zurückgeben, statt den Handler raten zu lassen.
Kurz gesagt
Body Ownership macht die Pipeline vorhersehbar: Der Handler bekommt einen fertigen parsed value und muss nicht selbst entscheiden, was mit dem Stream passiert ist.
Der Bun HTTP Server arbeitet mit dem Web Request/Response Modell. Deshalb sind die grundlegenden Body-Reading-Methoden aus der Fetch API bekannt: json(), text(), formData(), arrayBuffer(), blob() und Stream. [1][2]
| Methode | Wann nutzen | Was zurückkommt | Wichtigste Vorsicht |
|---|---|---|---|
req.json() | JSON API, JSON Webhooks, Config Mutations | Parsed JavaScript value | Fällt bei invalid JSON und braucht size/content-type/schema checks |
req.formData() | Forms, multipart uploads, gemischte text/file fields | FormData mit fields/files | Kann große Uploads buffern, deshalb sind file limits und storage policy nötig |
req.arrayBuffer() | Binary payload, signatures, raw webhook verification | ArrayBuffer | Kann Memory Pressure bei großen Payloads stark erhöhen |
req.text() | Plain text, raw signature input, kleine text payloads | String | Nicht geeignet für große Streams oder Uploads |
req.body stream | Große Payloads, streaming ingestion, custom parsers | ReadableStream oder null | Backpressure, limits und errors müssen selbst kontrolliert werden |
Die Wahl der Body API sollte von der Route abhängen. JSON, FormData, Binary und Streams sollten nicht durch einen universellen Parser laufen.
Screenshot des Abschnitts request-body-apisKurz gesagt
Ein universeller Body Parser ist am Anfang bequem, aber Production APIs sollten nach content-type und route purpose getrennt werden.
Für JSON Routes brauchst du nicht nur await req.json(), sondern ein kleines Gate: content-type prüfen, ungefähre content-length prüfen, Body lesen, parse errors behandeln, schema validieren und typed result weitergeben.
Ein minimaler nativer Bun Pattern:
type JsonContext<T> = { body: T };
type JsonHandler<T> = (req: Request, ctx: JsonContext<T>) => Promise<Response> | Response;
function jsonRoute<T>(schema: { parse: (value: unknown) => T }, handler: JsonHandler<T>) {
return async (req: Request) => {
const contentType = req.headers.get("content-type") ?? "";
if (!contentType.includes("application/json")) {
return Response.json({ error: "unsupported_media_type" }, { status: 415 });
}
const contentLength = Number(req.headers.get("content-length") ?? 0);
if (contentLength > 256_000) {
return Response.json({ error: "payload_too_large" }, { status: 413 });
}
try {
const raw = await req.json();
const body = schema.parse(raw);
return handler(req, { body });
} catch {
return Response.json({ error: "invalid_request_body" }, { status: 400 });
}
};
}In echtem Code ist es besser, parse error und validation error zu trennen, damit 400 für invalid JSON und 422 für schema mismatch zurückgegeben werden kann, wenn dein API Contract das unterstützt. Aber das Wichtigste ist: Der Handler liest den Body nicht mehr selbst.
Praktische Regel
JSON Middleware sollte typed body context erzeugen. Wenn der Handler erneut req.json() aufruft, funktioniert Ownership nicht.
File Upload ist eine der riskantesten API-Flächen. Das OWASP File Upload Cheat Sheet empfiehlt, Extensions zu begrenzen, Content Type zu prüfen, Filenames zu ändern, Size Limits zu setzen, Dateien außerhalb des Webroot zu speichern, Permissions zu prüfen und Dateien bei Bedarf zu scannen. [4]
In Bun sollte eine Upload Route nicht durch dieselbe JSON Middleware laufen. Upload braucht eigene Regeln: was hochgeladen werden darf, welches Maximum gilt, wo gespeichert wird, wie benannt wird, wann gescannt wird und ob asynchrone Verarbeitung nötig ist.
Wichtig ist die Trennung zwischen Metadata Validation und File Validation. Form Fields können per Schema validiert werden, aber die Datei braucht eigene Checks: size, declared MIME, magic bytes, extension allowlist, malware scanning, storage path.
Eine Upload Route braucht eine eigene Pipeline: size limit, type allowlist, scan/validation und eine sichere Storage-Entscheidung.
Screenshot des Abschnitts uploadsWenn eine Route einen großen Payload, Ingestion Stream, Media Upload oder long-running transfer akzeptiert, können arrayBuffer() und formData() die falsche Wahl sein. Sie sind bequem, können aber dazu führen, dass die Runtime erhebliche Datenmengen im Speicher halten muss.
Ein Streaming Flow verlangt ein anderes Denken: frühe Limits, Backpressure, Abort Handling, Timeout Policy, Storage Streaming, Partial Failures und Cleanup. Das ist nicht „ein normaler JSON Endpoint mit großem Body“.
Auch Observability ist bei Streams anders: Total request time kann lang und normal sein, deshalb sind Throughput, bytes accepted, time to first byte, storage errors und client aborts wichtig.
Große Payloads sollten durch die Pipeline gestreamt werden, nicht aus Bequemlichkeit für den Handler in einen großen Buffer verwandelt werden.
Screenshot des Abschnitts streamsKurz gesagt
Sobald ein Payload groß sein kann, wird Body Parsing zu einem Performance- und Reliability-Thema, nicht nur zu einem Validation Helper.
Schema Validation sollte nicht nur Typen prüfen. Sie sollte definieren, was mit unbekannten Feldern, Coercion, Defaults und Partial Updates passiert.
Strict schema
Gut für security-sensitive APIs: unbekannte Felder werden abgelehnt. Nachteil: Clients können bei zusätzlichen Feldern brechen.
Strip unknown
Praktisch für public APIs: zusätzliche Felder werden entfernt, Business Logic sieht einen sauberen Shape. Schema mismatch sollte vorsichtig geloggt werden.
Passthrough
Nur sinnvoll, wenn die API wirklich dynamic payload akzeptiert. Sonst entsteht Risiko für mass assignment oder versteckte Felder.
Coercion everywhere
Automatische Typumwandlung kann bequem sein, versteckt aber manchmal Client-Fehler. Bei money, permissions und security flags ist Strenge besser.
Kurz gesagt
Validation Policy sollte Teil des API Contract sein. Wenn jede Route unknown fields anders behandelt, verlieren Clients und Security Review schnell Vorhersehbarkeit.
POST/PUT Flows mit Payments, Orders, Webhook Retries, File Ingestion und Background Jobs haben ein eigenes Problem: Der Client kann den Request wiederholen, weil er keine Response bekommen hat oder einen Timeout erhielt. Body Validation sollte hier mit einem Idempotency Key zusammenarbeiten.
Idempotency Middleware prüft typischerweise Idempotency-Key, route group, subject/tenant und body hash. Wenn derselbe Key mit einem anderen Body kommt, sollte das ein Conflict sein und nicht eine zweite Ausführung der Mutation.
Das ist nicht für jede JSON Route nötig, aber für teure oder irreversible Operations oft günstiger, als doppelte Business Data nach einem Incident zu entwirren.
Praktische Regel
Wenn es gefährlich ist, eine Mutation zweimal auszuführen, sollte Body Validation eine Idempotency Story enthalten.
Diese Fehler entstehen meistens, wenn ein Team versucht, eine „universelle Body Middleware“ für die gesamte API zu bauen.
Globales await req.json() für alle Routes.
Body in mehreren Middleware-Schichten lesen, ohne parsed context weiterzugeben.
Payload Limit nach dem Parsing statt davor.
Ein Parser für JSON, multipart, binary und streams.
Raw body in Production loggen.
Kein 415 Unsupported Media Type für falschen content-type.
Uploads werden mit originalem filename in einem public directory gespeichert.
Validation lässt unknown fields in security-sensitive endpoints durch.
Keine Unterscheidung zwischen invalid JSON (400) und schema mismatch (422), obwohl der API Contract das braucht.
Large payload routes haben keine timeout, abort und cleanup policy.
Review-Regel
Ein Body Parser sollte route-specific sein. Wenn er „für alles funktioniert“, schützt er sehr wahrscheinlich keine wichtigen Edge Cases.
Vor dem Start einer Bun API in Staging oder Production sollte diese Liste für jede Endpoint-Klasse geprüft werden: JSON, Upload, Stream, Webhook und Mutation.
Body Owner ist definiert
Eine Middleware oder ein Route-Level Gate liest den Body und gibt parsed context weiter.
Content-Type wird geprüft
JSON, multipart, binary und streams haben unterschiedliche accepted content-types.
Size Limit läuft früh
Das Limit wird vor dem Parsing oder während streaming ingestion angewendet, nicht nach dem vollständigen Buffer.
Schema Validation hat eine Policy
Strict, strip oder passthrough Verhalten ist definiert und für die Route Class konsistent.
Uploads haben Security Controls
Extension/MIME allowlist, size limits, safe filename, storage policy, permissions und scanning bei Bedarf.
Streams haben Abort/Cleanup
Client abort, timeout, partial writes und storage errors werden explizit behandelt.
Errors sind stabil
400, 413, 415, 422 und 500 haben einen vorhersehbaren JSON Contract.
Body wird nicht geloggt
Logs enthalten request id, route, status, validation error class, aber keinen raw body oder file contents.
Bun gibt dir ein bequemes Web Request/Response Modell, aber genau deshalb vergisst man leicht, dass der Body ein Stream ist und kein normales Object. Gute Middleware liest den Body nicht „für alle Fälle“. Sie kennt route, method, content-type, size limit und schema.
JSON, Uploads, Streams und Binary Payloads brauchen unterschiedliche Pipelines. In Production wird ein universeller Parser oft zur Quelle von Memory Pressure, Validation Ambiguity und Security Risk.
Der beste Ansatz ist einfach: ein Body Owner, frühes Limit, richtiger Parser, typed validation result, stabiler Error Contract und separate Upload-/Stream-Policy. Das schließt die meisten Probleme, bevor der Handler erreicht wird.
Besser nicht. Der Request Body ist ein Stream und sollte einmal in der verantwortlichen Schicht gelesen werden. Gib den parsed value in den Context oder Handler weiter. Wiederholtes Lesen ohne Contract erzeugt fragile Bugs.
So früh wie möglich: vor teurem Parsing oder während streaming ingestion. Wenn zuerst `await req.json()` oder `await req.formData()` läuft, ist ein großer Payload bereits im Speicher.
Für Production besser nicht. JSON, multipart uploads, binary und streams haben unterschiedliche Security-, Memory- und Validation-Anforderungen. Sie sollten nach Route Classes getrennt werden.
`400` für invalid syntax oder malformed body, `413` für zu großen Payload, `415` für falschen content-type und `422` für schema mismatch, wenn dein API Contract Validation Errors unterscheidet.
Standardmäßig nein. Logge request id, route, error class, field names oder safe summary. Raw body kann PII, Credentials oder große Payloads enthalten.
Für Mutations, die gefährlich sind, wenn sie zweimal ausgeführt werden: Payments, Orders, Uploads, Webhook Processing, Job Creation. Der Idempotency Key sollte mit subject/tenant/route und body hash verbunden sein.
Diese Quellen bestätigen Web Request Body Methods, das Bun HTTP Server Modell und die Security Baseline für Uploads und Content Validation.
PAS7 Studio kann helfen, eine Validation Pipeline für Bun, Hono oder Elysia zu entwerfen: JSON schemas, upload security, payload limits, stream ingestion, idempotency keys, stable error contract und observability.
Das ist besonders nützlich für SaaS, Webhook Endpoints, File Ingestion, AI/Automation Flows und Migrationen von Express/Fastify, wo Body Parsing oft über Middleware, Handler und Validatoren verteilt ist.
Body Parsing und Validation in Bun.js: JSON, Uploads, Streams und Payload Limits
Sie sind hier: 05/05
Body Parsing und Validation in Bun.js: JSON, Uploads, Streams und Payload Limits
Verwandte Artikel
AI Assistant Entwicklung Kosten 2026: RAG, Knowledge Base, Integrationen und Support
Praktischer Leitfaden zu Kosten fuer AI Assistants: RAG, Knowledge Base, Channels, Tool Use, Guardrails, Evaluations, Monitoring und Support.
KI fur Landingpage-Entwicklung: wo sie Launches beschleunigt und wo sie Conversion schadet
Eine praxisnahe Analyse zur Nutzung von KI fur Landingpages: v0, Webflow AI, Builder.io, Framer-ahnliche Builder, UX-Generierung, Copy, SEO, Personalisierung, A/B-Tests, Template-Risiken, Accessibility, Security und technischer Schuldenaufbau.
AI SEO / GEO im Jahr 2026: Ihre nächsten Kunden sind nicht Menschen — sondern Agents
Suche verschiebt sich von Klicks zu Antworten. Bots und AI-Agents crawlen, zitieren, empfehlen — und kaufen zunehmend. Erfahren Sie, was AI SEO / GEO bedeutet, warum klassisches SEO nicht mehr reicht und wie PAS7 Studio Marken im agentischen Web sichtbar macht.
Der leistungsstärkste Chip von Apple? M5 Pro und M5 Max brechen Rekorde
Eine Analyse zu Apple M5 Pro und M5 Max im März 2026. Wir zeigen, warum diese Chips als die stärksten professionellen Laptop-SoCs von Apple gelten können, wie sie sich gegen M4 Pro, M4 Max, M1 Pro, M1 Max schlagen und was der Vergleich mit aktuellen Intel- und AMD-Chips zeigt.
Professionelle Entwicklung für Ihr Geschäft
Wir erstellen moderne Web-Lösungen und Bots für Unternehmen. Erfahren Sie, wie wir Ihnen helfen können, Ihre Ziele zu erreichen.