Tehnologija
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
Većina Node/Nest tehnoloških paketa tiho prihvaća duple ključeve u JSON-u (last-one-wins). To je stvaran sigurnosni i funkcionalni rizik. Ovdje su model prijetnji, usporedba alata i razlog zašto je PAS7 Studio izradio @pas7/nestjs-strict-json.
Š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 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]
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 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 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]
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 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 (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.
Izvori i reference
Ključni standardi i sigurnosne reference korištene u ovom članku.
FAQ
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]
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]
Validacija se obično radi *nakon* parsinga, pa često vidi samo finalni shape objekta nakon kolapsa duplikata. Strict JSON pokušava uhvatiti dvosmislenost ranije.
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.
Želiš sigurnije NestJS API-je? Kreni od strogih input contracta
Ako ti je backend “secure by DTO”, strict parsing je često prvi korak koji nedostaje: validiraj tek nakon što je payload jednoznačan.