Closed (won't fix)
Project:
Drupal core
Version:
11.x-dev
Component:
render system
Priority:
Major
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
5 Jun 2015 at 18:52 UTC
Updated:
27 Jun 2025 at 08:13 UTC
Jump to comment: Most recent
Comments
Comment #1
xjmThanks @lokapujya for getting this filed!
Comment #2
xjmComment #3
joelpittetIMO regarding JSON, it needs to remain as strings. So in the case of the
SafeStringobjects that now exist, we need to ensure they are cast to(string)before encoded. ForSafeMarkup, JSON should remain as-is and the consuming application will have to sanitize or not the values like in D7, they could be checked against the giant array of safe strings if within the same request, but I'd rather leave that assumption up to the consumer.@lokapujya could you add other examples of non-HTML that come to mind?
Comment #4
wim leersComment #5
lokapujyarender arrays, XML, FBML
I guess if another system or site trusts the Drupal output it wouldn't need to run it's own sanitization. It wasn't really my idea, I just filed the issue. "the consuming application will have to sanitize or not the values" - might be the way to go for now.
Comment #6
davidhernandezKind of agree with Joel's point of view here. And that is consist with the general Drupal philosophy that the data mostly stay untouched. But that is more of a philosophical/policy discussion than a technical one. I think the difference is that html output is something that we consider end-user facing output, and thus sanitize it. If we don't consider json, et al to be end-user facing, and I don't think we do, then don't sanitize it.
Question, though - Do we think that leaving the burden of sanitizing/safeguarding/whatever the data up to the consuming application is a hassle? I'm sure there are use-cases where it would be helpful to at least have the option of telling Drupal to only give me safe data.
Comment #7
wim leersIt's not just philosophical. If you get filtered/escaped data for a node's body field, you're no longer able to edit the data that is actually stored. So there's solid technical reasons for it too.
Comment #8
joelpittetWith this discussion are there some next steps to take? Are we currently sanitizing json or other format data that we shouldn't be?
Comment #22
smustgrave commentedThank you for creating this issue to improve Drupal.
We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.
Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.
Thanks!
Comment #23
xjmDrupal picked an architectural direction for this in that REST and JSON:API do not use the Render system, and it is the client's responsibility to perform rendering and sanitization rather than Twig's or core utilities'.
Comment #24
xjmMaybe more a wontfix, actually.