JSON

JSON blev udbredt af Douglas Crockford fra omkring 2001 som en delmængde af JavaScripts syntaks for literaler. Formatet blev først beskrevet i RFC 4627 (2006), og i dag definerer to afstemte specifikationer det: RFC 8259 (december 2017, internetstandard STD 90) og ECMA-404 (2. udgave, 2017). Grammatikken er lille: objekter, arrays, strenge, tal og literalerne true, false og null. Betydningsløst whitespace er begrænset til mellemrum, tabulator, linjeskift og vognretur; der er ingen kommentarer, ingen afsluttende kommaer, ingen strenge i enkelte anførselstegn og ingen NaN eller Infinity. Kontroltegn fra U+0000 til U+001F skal escapes i strenge, og tegn uden for Basic Multilingual Plane skrives som \u-escapede surrogatpar. Medietypen er application/json.

Hullerne i interoperabiliteten er bevidste og har betydning i praksis. RFC 8259 afsnit 4 siger, at navne i et objekt SHOULD være unikke, men lader dubletter være udefinerede: JavaScripts JSON.parse beholder den sidste værdi, andre parsere den første, eller de afviser dokumentet. Når et sikkerhedsfilter og en back-end bruger forskellige parsere, kan en dubleret nøgle betyde én ting for kontrollen og noget andet for modtageren. Tal har ingen præcisionsgrænse i grammatikken, men afsnit 6 bemærker, at IEEE 754 binary64 er udbredt, så heltal uden for intervallet -(2^53)+1 til (2^53)-1 mister præcision i JavaScript; derfor sender API'er ofte store id'er som strenge. Afsnit 8.1 kræver UTF-8 for JSON, der udveksles mellem systemer uden for et lukket økosystem. I-JSON-profilen (RFC 7493) lukker hullerne ved at forbyde dubletnavne og begrænse tal og tegnkodning.

Sikkerhedsproblemer opstår mest efter parsingen. Tidlig kode evaluerede JSON med eval(), som udførte ethvert indlejret script. I JavaScript kan sammenfletning af parsede objekter med en "__proto__"-nøgle føre til prototype pollution. Biblioteker, der instantierer typer navngivet i input, som polymorf typning i Jackson eller TypeNameHandling i Json.NET, har givet fejl med fjernkørsel af kode, klassificeret som usikker deserialisering (CWE-502). Dybt indlejret eller enormt input kan opbruge stak eller hukommelse, så parsere har brug for grænser for dybde og størrelse. Til signaturer signerer JOSE (JWS, RFC 7515; JWT, RFC 7519) de base64url-kodede bytes for at undgå kanonisering, mens JSON Canonicalization Scheme (RFC 8785) definerer en kanonisk form, hvor der er brug for en.

Omkring kernen findes et økosystem: JSON Schema (draft 2020-12, også brugt af OpenAPI 3.1) til validering, JSON Pointer (RFC 6901), JSON Patch (RFC 6902) og JSON Merge Patch (RFC 7396) til delvise opdateringer samt linjeopdelt JSON til streaming. Sammenlignet med XML har JSON ingen attributter, navnerum eller entitetsudvidelse, så XXE-lignende angreb er irrelevante; YAML 1.2 er designet som en overmængde af JSON; og Protocol Buffers bytter læsbarhed for en kompakt binær kodning med obligatorisk skema.