5 ms·

If you're evaluating JSON as JavaScript, you also need to make sure none of the objects have a key named "proto", or else you can end up with some strange r

by comex 1y ago

If you're evaluating JSON as JavaScript, you also need to make sure none of the objects have a key named "__proto__", or else you can end up with some strange results. (This is related to the 'prototype pollution' attack, although searching that phrase will mostly give you information about the more-dangerous variant where two objects are being merged together with some JS library. If __proto__ is just part of a literal, the behavior is not as dangerous, but still surprising.)

o11c 1y ago
But note that there's also `<script type="application/json">` these days (usually only useful with `id=`) ... and `importmap` I guess.
- themafia 1y ago
  It's even more general: type This attribute indicates the type of script represented. The value of this attribute will be one of the following: [...] Any other value The embedded content is treated as a data block, and won't be processed by the browser. Developers must use a valid MIME type that is not a JavaScript MIME type to denote data blocks. All of the other attributes will be ignored, including the src attribute. Although 'importmap' has specific functionality, as does 'speculationrules', although they operate similarly. My favorite is type="module" which competes with the higher level attribute nomodule="true". Anyways it looks like <script> has taken a lot of abuse over the years: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/script https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
  - masklinn 1y ago
    > My favorite is type="module" which competes with the higher level attribute nomodule="true". Anyways it looks like <script> has taken a lot of abuse over the years: It "conflicts" in the same way noscript[1] and script "conflict" no? They're basically related features, but can't really be made exclusive because the mere act of trying to do so wouldn't work: as the link indicates, executing code in a !module browser reserves the type (requires a specific set of types) so you can't use that as a way to opt in !module browsers. [1] an other fun element with wonky parsing rules besides
    - themafia 1y ago
      You can write: <script nomodule="true" type="module"></script> Which is a little weird. At the very least I'd expect the type="module" documentation to say that `charset`, `defer` and `nomodule` attributes have no effect.
      - domenicd 1y ago
        It does? https://html.spec.whatwg.org/multipage/scripting.html#attr-script-src https://html.spec.whatwg.org/multipage/scripting.html#attr-s...
        themafia 1y ago
        It specifies it in the abstract. Did you mean to link here instead of to the 'src' attribute documentation? https://html.spec.whatwg.org/multipage/scripting.html#attr-script-nomodule:~:text=If%20el%20has%20a%20nomodule,effect%3B%20the%20algorithm%20continues%20onward https://html.spec.whatwg.org/multipage/scripting.html#attr-s.... My expectation was that this condition would have been reflected in MDNs documentation where it breaks the conditions for 'charset' and 'defer' out.
        masklinn 1y ago
        Why? MDN does not purport to be exhaustive, that's the spec's job.
        themafia 1y ago
        MDN does a pretty good job anyways. Perhaps I feel that it would be in keeping with that spirit to have this condition documented. This is partly because MDN is far easier to read for the purposes of _reference_ than the spec which is easier to read for the purposes of _implementing_. It's also easier to search and to share links to, as the link you presented earlier was both wrong and confusing, and there was no natural way to link to the part of the document you intended. Perhaps the spec isn't the right tool for every job? That's why, for me, at least.
- jgalt212 1y ago
  Why does the author ignore this method? Django docs show this as a best practice via a built in tag.
- minitech 1y ago
  Yes, that option is the real “just do this”. - escape `<` as `\u003c` <script id="my-json" type="application/json">{{ escaped_json }}</script> JSON.parse(document.getElementById('my-json').textContent) No __proto__ issue, and no dynamic code at all, so you can use a strict CSP.
pwdisswordfishz 1y ago
Or you can use JSON.parse with a string literal on the client side. Which is, surprisingly, more performant than parsing at compile time. https://www.youtube.com/watch?v=ff4fgQxPaO0 https://www.youtube.com/watch?v=ff4fgQxPaO0

If you're evaluating JSON as JavaScript, you also need to make sure none of the objects have a key named "__proto__", or else you can end up with some strange r

by comex 1y ago

o11c 1y ago

But note that there's also `<script type="application/json">` these days (usually only useful with `id=`) ... and `importmap` I guess.

themafia 1y ago
It's even more general: type This attribute indicates the type of script represented. The value of this attribute will be one of the following: [...] Any other value The embedded content is treated as a data block, and won't be processed by the browser. Developers must use a valid MIME type that is not a JavaScript MIME type to denote data blocks. All of the other attributes will be ignored, including the src attribute. Although 'importmap' has specific functionality, as does 'speculationrules', although they operate similarly. My favorite is type="module" which competes with the higher level attribute nomodule="true". Anyways it looks like <script> has taken a lot of abuse over the years: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/script https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
- masklinn 1y ago
  > My favorite is type="module" which competes with the higher level attribute nomodule="true". Anyways it looks like <script> has taken a lot of abuse over the years: It "conflicts" in the same way noscript[1] and script "conflict" no? They're basically related features, but can't really be made exclusive because the mere act of trying to do so wouldn't work: as the link indicates, executing code in a !module browser reserves the type (requires a specific set of types) so you can't use that as a way to opt in !module browsers. [1] an other fun element with wonky parsing rules besides
  - themafia 1y ago
    You can write: <script nomodule="true" type="module"></script> Which is a little weird. At the very least I'd expect the type="module" documentation to say that `charset`, `defer` and `nomodule` attributes have no effect.
    - domenicd 1y ago
      It does? https://html.spec.whatwg.org/multipage/scripting.html#attr-script-src https://html.spec.whatwg.org/multipage/scripting.html#attr-s...
      - themafia 1y ago
        It specifies it in the abstract. Did you mean to link here instead of to the 'src' attribute documentation? https://html.spec.whatwg.org/multipage/scripting.html#attr-script-nomodule:~:text=If%20el%20has%20a%20nomodule,effect%3B%20the%20algorithm%20continues%20onward https://html.spec.whatwg.org/multipage/scripting.html#attr-s.... My expectation was that this condition would have been reflected in MDNs documentation where it breaks the conditions for 'charset' and 'defer' out.
        masklinn 1y ago
        Why? MDN does not purport to be exhaustive, that's the spec's job.
        themafia 1y ago
        MDN does a pretty good job anyways. Perhaps I feel that it would be in keeping with that spirit to have this condition documented. This is partly because MDN is far easier to read for the purposes of _reference_ than the spec which is easier to read for the purposes of _implementing_. It's also easier to search and to share links to, as the link you presented earlier was both wrong and confusing, and there was no natural way to link to the part of the document you intended. Perhaps the spec isn't the right tool for every job? That's why, for me, at least.
jgalt212 1y ago
Why does the author ignore this method? Django docs show this as a best practice via a built in tag.
minitech 1y ago
Yes, that option is the real “just do this”. - escape `<` as `\u003c` <script id="my-json" type="application/json">{{ escaped_json }}</script> JSON.parse(document.getElementById('my-json').textContent) No __proto__ issue, and no dynamic code at all, so you can use a strict CSP.

pwdisswordfishz 1y ago

Or you can use JSON.parse with a string literal on the client side. Which is, surprisingly, more performant than parsing at compile time. https://www.youtube.com/watch?v=ff4fgQxPaO0 https://www.youtube.com/watch?v=ff4fgQxPaO0