Technologie
Doppelte JSON-Keys in NestJS: warum das gefährlich ist, was andere übersehen, und wie @pas7/nestjs-strict-json es behebt
Die meisten Node/Nest-Stacks akzeptieren doppelte JSON-Keys stillschweigend (last-one-wins). Das ist ein echtes Sicherheits- und Korrektheitsrisiko. Hier zeigen wir Threat Model, Tool-Landschaft und warum PAS7 Studio @pas7/nestjs-strict-json entwickelt hat.
Was du aus diesem Artikel mitnimmst
Ein praxisnaher Deep-Dive für Backend-Engineers: Threat Model, wie Duplicate Keys „in the wild“ wirken, was gängige Tools tun (und nicht tun) und welchen Ansatz wir in @pas7/nestjs-strict-json umgesetzt haben.
• Warum Duplicate Keys überhaupt vorkommen und warum Standards davor warnen. [1]
• Warum „last-one-wins“ Parsing ein Risiko für Korrektheit und Security ist. [2][3]
• Konkurrenz-Überblick: was Libraries wie secure-json-parse lösen (und was nicht). [4]
• Wie @pas7/nestjs-strict-json sich sauber in NestJS integriert, ohne dein API zur Bastelarbeit zu machen.
• Empfohlene Rollout-Strategie: Strict Mode ohne sofortige Production-Breaks.
Warum Duplicate Keys ein echtes Problem sind (keine Pedanterie)
JSON-Objekt-Member-Namen *sollten* eindeutig sein, damit Verhalten vorhersehbar bleibt. Der JSON-Standard warnt explizit: bei nicht eindeutigen Namen kann das Verhalten nicht interoperabel sein, und manche Implementierungen behalten den letzten Wert. Das ist nicht hypothetisch — es passiert in echten Parsern und echten APIs. [1]
Der Footgun ist simpel: verschiedene Schichten interpretieren denselben Payload unterschiedlich. Dein Gateway sieht vielleicht den ersten Wert, die App den letzten, Logging etwas anderes — und Signaturen/Verifikation können ausgetrickst werden, wenn Serialisierung/Normalisierung unterschiedlich läuft. Diese Klasse von Issues ist in Security-Research zu JSON-Interoperabilität gut dokumentiert. [3]
Threat Model: wo Duplicate Keys dir weh tun
Duplicate Keys sind ein klassischer „wirkt harmlos“-Trick. Häufige Failure Modes, die wir bei Teams sehen:
• Authorization-Confusion: Proxy/Middleware prüft einen Wert, die App nutzt einen anderen (role / scope / isAdmin).
• Validation-Bypass: Schema validiert eine Darstellung, Business-Logic konsumiert eine andere.
• Audit/Logging-Mismatch: Incident Response wird schwer, wenn Logs nicht dem effektiven Payload entsprechen.
• WAF/Cache/Signature-Inkonsistenzen: Security-Tools normalisieren anders als Runtime-Parser (Interoperabilitäts-Bugs). [3]
Konkurrenz und warum das nicht vollständig abgedeckt ist
Es gibt hervorragende Libraries zum Hardening von JSON-Parsing, aber viele fokussieren eine andere Angriffsfläche als Duplicate Keys.
secure-json-parse (Fastify-Ökosystem)
Eine weit verbreitete Drop-in-Parser-Alternative, primär gegen Prototype Poisoning wie __proto__ und constructor.prototype. Dafür ist sie top, aber das ist nicht „Duplicate-Keys-Strictness“ per Default. Eher *Prototype-Safety* statt *semantischer Eindeutigkeit* von Keys. [4]
Typische NestJS-Stacks (Express/Fastify Defaults)
Die meisten Setups verlassen sich auf Standard-JSON-Parsing und validieren danach (DTO/class-validator/zod). Wenn Duplicate Keys beim Parsing bereits kollabieren, sieht der Validator nur die finale Form — und der Trick ist oft unsichtbar.
Custom Middleware / manuelle Checks
Manche Teams patchen das mit Ad-hoc-Middleware. Das führt zu inkonsistentem Verhalten pro Route, fragiler Adapter-Integration (Express vs Fastify) und fehlender Testabdeckung. Wir wollten einen sauberen, wiederverwendbaren, Nest-nativen Ansatz.
@pas7/nestjs-strict-json
Unser Fokus: Duplicate Keys früh und konsistent erkennen und ablehnen, mit vorhersehbarem Verhalten in deiner NestJS-App. Ziel wie bei „strict input contracts“: fail fast, fail loudly, und saubere Observability.
Was der Standard wirklich sagt
RFC 8259 warnt, dass Member-Namen eindeutig sein sollten und dass Nicht-Eindeutigkeit nicht interoperabel ist. Anders gesagt: „es parst“ ist nicht die Messlatte — *Vorhersehbarkeit über Tooling hinweg* ist die Messlatte. [1]
Security-Research geht weiter: Unterschiede beim Parsing/Normalisieren zwischen Komponenten können echte Vulnerabilities erzeugen (JSON Interoperability Issues). Duplicate Keys sind dabei ein häufiger Bestandteil solcher Mismatches. [3]
Wie @pas7/nestjs-strict-json in der Praxis hilft
Die Intention ist simpel: sicherstellen, dass Request-JSON eine *eindeutige Map* ist (keine Duplicate Keys), bevor Controller, DTO-Validation oder Business-Logic laufen.
• Duplicate Keys früh ablehnen (vor Validation/Business-Logic).
• Konsistentes Verhalten über Environments hinweg (local, staging, production).
• Explizite, debuggable Fehler statt stiller Overwrites.
• Nest-freundliche Integration (fühlt sich nach Nest an, nicht nach Script-Glue).
Rollout-Strategie (brich nicht aus Versehen die Produktion)
Wenn du bereits Clients in freier Wildbahn hast, sollten strikte Input-Checks vorsichtig ausgerollt werden. Ein sicherer Pfad:
• Starte zunächst im Nur-Bericht-Modus (Duplicate-Key-Vorkommen protokollieren) für ein kurzes Zeitfenster.
• Fixe/kontaktiere die größten Offender — Duplicate Keys sind oft Serializer-Bugs.
• Aktiviere strikte Ablehnung schrittweise pro Route-Gruppe (auth/admin zuerst).
• Mach es zur Plattform-Policy: „Duplicate Keys sind invalid input“. Dokumentiere es im API-Contract.
Über PAS7 Studio (warum wir es open-sourced haben)
Wir bauen performance-first Web-Produkte und Backend-Systeme und sehen immer wieder dasselbe: Teams verschwenden Zeit mit „unmöglichen Zuständen“, die durch mehrdeutigen Input entstehen. Strict JSON ist eine kleine Leitplanke, die eine ganze Klasse von Problemen verhindert.
Darum haben wir @pas7/nestjs-strict-json open-sourced: damit Strictness in NestJS-Projekten einfach, konsistent und testbar wird.
Quellen und Referenzen
Zentrale Standards und Security-Referenzen, die in diesem Artikel verwendet wurden.
FAQ
Der JSON-Standard warnt, dass nicht eindeutige Namen zu nicht interoperablem Verhalten führen; viele Implementierungen akzeptieren es und behalten den letzten Wert. Genau dieser Mismatch macht es riskant. [1][2]
secure-json-parse zielt primär auf Prototype Poisoning (__proto__/constructor.prototype). Es ist stark für diese Kategorie, aber nicht dasselbe wie die Durchsetzung eindeutiger Keys in JSON-Objekten. [4]
Validation läuft typischerweise *nach* dem Parsing, also sieht sie oft nur die finale Objektform, nachdem Duplicate Keys kollabiert sind. Strict JSON zielt darauf, die Mehrdeutigkeit früher zu erkennen.
Beginne im Nur-Bericht-Modus für Duplicate-Key-Payloads, behebe die Top-Clients und aktiviere strikte Ablehnung schrittweise pro Route-Gruppe. Behandle es als Regel deines API-Vertrags.
Willst du sicherere NestJS APIs? Fang mit strikten Input-Contracts an
Wenn dein Backend „secure by DTO“ ist, fehlt oft der erste Schritt: erst sicherstellen, dass der Payload eindeutig ist — dann validieren.