Dupli JSON ključevi u NestJS-u: zašto je to opasno, što drugi propuštaju i kako to rješava @pas7/nestjs-strict-json

Što ćeš dobiti

Što ćeš dobiti iz ovog članka

Praktični dubinski pregled za backend inženjere: model prijetnji, kako se dupli ključevi ponašaju u praksi, što popularni alati rade (i ne rade) te pristup koji smo implementirali u @pas7/nestjs-strict-json.

Zašto dupli ključevi uopće postoje i zašto standardi upozoravaju na njih. [1]

Zašto je “last-one-wins” parsing rizik za ispravnost i sigurnost. [2][3]

Pregled konkurencije: što rješavaju biblioteke poput secure-json-parse (a što ne). [4]

Kako se @pas7/nestjs-strict-json uklapa u NestJS bez nepotrebne komplikacije.

Preporučena strategija uvođenja: strogi način rada bez rušenja produkcijskih klijenata preko noći.

Zašto su dupli

Zašto su dupli ključevi stvaran problem (nije cjepidlačenje)

Nazivi članova JSON objekta *trebali bi* biti jedinstveni kako bi ponašanje bilo predvidljivo. JSON standard eksplicitno upozorava: kad imena nisu jedinstvena, implementacije mogu imati nepredvidivo ponašanje, a neke zadržavaju zadnju vrijednost. To nije hipotetski — događa se u stvarnim parserima i stvarnim API-jima. [1]

Problem je jednostavan: različiti slojevi mogu različito interpretirati isti payload. Gateway može vidjeti prvu vrijednost, aplikacija zadnju, logiranje nešto treće, a potpis/verifikacija se može prevariti ako se serializacija/normalizacija razlikuje po komponentama. Ova klasa problema dobro je dokumentirana u sigurnosnim istraživanjima o JSON interoperabilnosti. [3]

Model prijetnji

Threat model: gdje dupli ključevi štete

Dupli ključevi su klasičan “izgleda bezazleno” trik. Evo tipičnih failure mode-ova koje vidimo kod timova:

Zbunjenost u autorizaciji: proxy ili middleware provjeri jednu vrijednost, a aplikacija koristi drugu (role / scope / isAdmin).

Zaobilaženje validacije: shema validira jednu reprezentaciju, business logika konzumira drugu.

Nesklad audita/logova: incident response je teži kad logovi ne odgovaraju efektivnom payloadu.

Nedosljednosti WAF/cache/signature: sigurnosni alati normaliziraju drugačije od runtime parsera (interoperability bugovi). [3]

Konkurencija zašto ne

Konkurencija i zašto ne pokriva sve

Postoje odlične biblioteke za hardening JSON parsinga, ali mnoge ciljaju drugačiju površinu napada od duplih ključeva.

secure-json-parse (Fastify ekosustav)

Široko korišten drop-in parser fokusiran na prototype poisoning rizike poput __proto__ i constructor.prototype. Odličan je za tu kategoriju, ali to nije isto što i striktna detekcija duplih ključeva po defaultu. To je *sigurnost prototipa*, ne *semantička jedinstvenost ključeva*. [4]

Tipični NestJS stackovi (Express/Fastify default)

Većina setupa se oslanja na standardni JSON parsing i zatim radi validaciju (DTO/class-validator/zod). Ali ako se duplikati kolabiraju tijekom parsinga, validatori vide samo finalni shape — i trik je često nevidljiv.

Custom middleware / ručne provjere

Timovi ponekad zakrpaju ovo ad-hoc middlewareom. To često vodi do nekonzistentnog ponašanja po rutama, krhkih integracija s adapterima (Express vs Fastify) i manjka test pokrivenosti. Htjeli smo čist, reusabilan, Nest-native pristup.

@pas7/nestjs-strict-json

Naš fokus: detektirati i odbiti JSON s duplim ključevima rano i konzistentno, s predvidljivim ponašanjem kroz cijelu NestJS aplikaciju. Cilj kao kod “strict input contracts”: fail fast, fail loudly i uredna observability.

Što standard zapravo

Što standard zapravo kaže

RFC 8259 upozorava da bi nazivi članova trebali biti jedinstveni, a kad nisu, ponašanje nije interoperabilno. Drugim riječima: “prođe parsing” nije dovoljno — bitna je *predvidljivost kroz cijeli toolchain*. [1]

Sigurnosna istraživanja idu dalje: razlike u parsingu/normalizaciji između komponenti mogu stvoriti stvarne ranjivosti (JSON interoperability issues). Dupli ključevi su čest sastojak takvih nesklada. [3]

pas7/nestjs-strict-json pomaže praksi

Kako @pas7/nestjs-strict-json pomaže u praksi

Namjera je jednostavna: osigurati da request JSON bude *jednoznačna mapa* (bez duplih ključeva) prije nego dođe do kontrolera, DTO validacije ili business logike.

Odbaci duple ključeve rano (prije validacije/business logike).

Konzistentno ponašanje kroz okruženja (local, staging, production).

Jasni, debuggable errori umjesto tihih overwriteova.

Integracija prilagođena NestJS-u (osjeća se kao dio frameworka, ne kao nasumična skripta).

Strategija uvođenja ne

Strategija uvođenja (ne razbij produkciju slučajno)

Ako već imaš klijente u stvarnom svijetu, stroge provjere inputa uvedi pažljivo. Siguran put:

Kreni s načinom samo za izvještavanje (logiraj pojave duplih ključeva) kratko vrijeme.

Ispravi/kontaktiraj top klijente; duplikati su često greške serializer-a.

Postupno uključi strogo odbijanje po grupama ruta (auth/admin prvo).

Postavi to kao platformsku politiku: “dupli ključevi su nevalidan input”. Napiši to u API contract.

O PAS7 Studio

O PAS7 Studio (zašto smo to open-sourceali)

Gradimo performance-first web proizvode i backend sustave i stalno nailazimo na isti problem: timovi troše vrijeme na “nemoguća stanja” uzrokovana dvosmislenim inputom. Strict JSON je mala zaštita koja sprječava cijelu klasu problema.

Zato smo open-sourceali @pas7/nestjs-strict-json: da strictness bude jednostavan, konzistentan i testabilan u NestJS projektima.

FAQ

ČPP

Je li ponašanje s duplim ključevima stvarno nedefinirano?

JSON standard upozorava da nejedinstvena imena vode do neinteroperabilnog ponašanja; mnoge implementacije to prihvaćaju i zadržavaju zadnju vrijednost. Upravo taj mismatch je rizik. [1][2]

Rješava li secure-json-parse duple ključeve?

secure-json-parse primarno cilja prototype poisoning (__proto__/constructor.prototype). To je odličan sloj za tu kategoriju, ali nije isto što i forsiranje jedinstvenih ključeva u JSON objektima. [4]

Ne može li validacija (DTO/Zod) to uhvatiti?

Validacija se obično radi *nakon* parsinga, pa često vidi samo finalni shape objekta nakon kolapsa duplikata. Strict JSON pokušava uhvatiti dvosmislenost ranije.

Kako uvesti strict JSON bez rušenja klijenata?

Počni s načinom samo za izvještavanje za payloadove s duplim ključevima, popravi top klijente, zatim postupno uključi strogo odbijanje po grupama ruta. Tretiraj to kao pravilo API ugovora.

Izvori reference