Tecnologia
Chiavi JSON duplicate in NestJS: perché è pericoloso, cosa gli altri si perdono e come @pas7/nestjs-strict-json lo risolve
La maggior parte dei pacchetti tecnologici Node/Nest accetta in silenzio chiavi JSON duplicate (last-one-wins). È un problema reale di sicurezza e correttezza. Qui trovi il modello di minaccia, il confronto con le alternative e perché PAS7 Studio ha creato @pas7/nestjs-strict-json.
Cosa otterrai da questo articolo
Un approfondimento pratico per backend engineer: modello di minaccia, comportamento reale delle chiavi duplicate, cosa fanno (e non fanno) gli strumenti più comuni e approccio adottato in @pas7/nestjs-strict-json.
• Perché esistono le chiavi duplicate e perché gli standard ti avvertono. [1]
• Perché il parsing “last-one-wins” è un rischio di correttezza e sicurezza. [2][3]
• Panoramica competitor: cosa risolvono librerie come secure-json-parse (e cosa no). [4]
• Come @pas7/nestjs-strict-json si integra in NestJS senza trasformare l’API in un progetto complicato.
• Strategia di rollout consigliata: modalità rigorosa senza rompere i client in produzione dall’oggi al domani.
Perché le chiavi duplicate sono un problema reale (non pedanteria)
I nomi dei membri negli oggetti JSON *dovrebbero* essere univoci per avere un comportamento prevedibile. Lo standard JSON avverte esplicitamente: se i nomi non sono univoci, le implementazioni possono comportarsi in modo non interoperabile e alcune manterranno l’ultimo valore. Non è teoria — succede con parser reali e API reali. [1]
Il rischio è semplice: layer diversi possono interpretare lo stesso payload in modo diverso. Il gateway può vedere il primo valore, l’app l’ultimo, il logging qualcosa di diverso; e firme/verifiche possono essere ingannate se serializzazione/normalizzazione differiscono. Questa classe di problemi è ben documentata nella ricerca sulla JSON interoperability. [3]
Threat model: dove le chiavi duplicate ti colpiscono
Le chiavi duplicate sono un classico trucco “sembra innocuo”. Ecco i failure mode più comuni che abbiamo visto nei team:
• Confusione in autorizzazione: un proxy o middleware controlla un valore, l’app ne usa un altro (role / scope / isAdmin).
• Bypass di validazione: lo schema valida una rappresentazione, la business logic consuma un’altra.
• Mismatch di audit/log: la risposta a incidenti diventa più difficile se i log non corrispondono al payload effettivo.
• Incoerenze tra WAF/cache/firme: strumenti di sicurezza normalizzano diversamente dai parser runtime (bug di interoperabilità). [3]
Concorrenza e perché non copre tutto
Ci sono librerie ottime per hardening del parsing JSON, ma molte si concentrano su una superficie d’attacco diversa dalle chiavi duplicate.
secure-json-parse (ecosistema Fastify)
Parser drop-in molto usato, focalizzato su rischi di prototype poisoning come __proto__ e constructor.prototype. È ottimo per quella categoria, ma non è “strict duplicate-keys” di default. È *sicurezza del prototipo*, non *unicità semantica* delle chiavi. [4]
Stack NestJS tipici (default Express/Fastify)
La maggior parte dei setup si affida al parsing JSON standard e poi valida (DTO/class-validator/zod). Ma se i duplicati collassano durante il parsing, i validator vedono solo la forma finale — e il trucco può sparire.
Middleware custom / controlli manuali
A volte i team patchano con middleware ad-hoc. Spesso porta a comportamento incoerente tra route, integrazioni fragili con adapter (Express vs Fastify) e buchi di test. Volevamo un approccio pulito, riusabile e Nest-native.
@pas7/nestjs-strict-json
Focus: rilevare e rifiutare JSON con chiavi duplicate presto e in modo consistente, con comportamento prevedibile in tutta l’app NestJS. Stessa filosofia dei “strict input contracts”: fail fast, fail loudly e osservabilità pulita.
Cosa dice davvero lo standard
RFC 8259 avverte che i nomi dei membri dovrebbero essere univoci e che, in caso contrario, il comportamento non è interoperabile. In altre parole: “viene parsato” non basta — conta la *prevedibilità lungo tutta la toolchain*. [1]
La ricerca security va oltre: differenze di parsing/normalizzazione tra componenti possono creare vulnerabilità reali (JSON interoperability issues). Le chiavi duplicate sono spesso parte di questi mismatch. [3]
Come @pas7/nestjs-strict-json aiuta nella pratica
L’intento è semplice: assicurarsi che il JSON della richiesta sia una *mappa non ambigua* (senza chiavi duplicate) prima di controller, validazione DTO o business logic.
• Rifiuta le chiavi duplicate presto (prima di validazione/business logic).
• Comportamento coerente tra ambienti (local, staging, production).
• Errori espliciti e debuggable invece di overwrite silenziosi.
• Integrazione nativa per NestJS (sembra parte del framework, non uno script improvvisato).
Strategia di rollout (non rompere la prod per sbaglio)
Se hai già client in produzione, i controlli strict vanno introdotti con cura. Un percorso sicuro:
• Inizia in modalità solo report (log delle occorrenze) per un breve periodo.
• Sistema/contatta i client principali: spesso sono bug di serializer.
• Abilita il rifiuto strict gradualmente per gruppi di route (auth/admin prima).
• Rendilo una policy di piattaforma: “le chiavi duplicate sono input non valido”. Inseriscilo nel contratto API.
Su PAS7 Studio (perché lo abbiamo open-sourced)
Costruiamo prodotti web performance-first e sistemi backend, e vediamo spesso lo stesso problema: tempo perso a debuggare “stati impossibili” causati da input ambiguo. Strict JSON è una piccola guardrail che previene un’intera classe di problemi.
Per questo abbiamo open-sourced @pas7/nestjs-strict-json: per rendere la strictness semplice, consistente e testabile nei progetti NestJS.
Fonti e riferimenti
Standard e riferimenti security principali usati in questo articolo.
• 1. RFC 8259 — JSON e note di interoperabilità sui nomi univoci dei membri Read source ↗
• 3. Bishop Fox — JSON Interoperability Vulnerabilities (panoramica della ricerca) Read source ↗
• 4. fastify/secure-json-parse — sostituto drop-in di JSON.parse per protezione da prototype poisoning Read source ↗
FAQ
Lo standard JSON avverte che nomi non univoci portano a comportamento non interoperabile; molte implementazioni lo accettano e tengono l’ultimo valore. Proprio questo mismatch lo rende rischioso. [1][2]
secure-json-parse è principalmente per la protezione da prototype poisoning (__proto__/constructor.prototype). È ottimo per quella categoria, ma non è la stessa cosa che imporre unicità delle chiavi negli oggetti JSON. [4]
La validazione di solito avviene *dopo* il parsing, quindi spesso vede solo la forma finale dell’oggetto dopo che i duplicati sono collassati. Strict JSON mira a catturare l’ambiguità prima.
Inizia con modalità solo report per i payload con chiavi duplicate, correggi i client principali, poi abilita il rifiuto rigoroso gradualmente per gruppi di route. Trattalo come regola del tuo contratto API.
Vuoi API NestJS più sicure? Parti da contratti di input strict
Se il tuo backend è “secure by DTO”, lo strict parsing è spesso il primo passo mancante: valida dopo aver reso il payload non ambiguo.