This is a potential footgun with maud: the path of less resistance, letting maud do the escaping, means that the scripts and styles get mangled; however, naively using PreEscaped could theoretically introduce an XSS vulnerability because then there's no check for an errant </.
This is related to #88. I'm afraid that the HTML syntax is so complicated that there's no way to avoid a certain amount of context-awareness here. I don't know what the ideal API looks like, or even if maud can do much better, but at the very least the docs should point out the footgun here.
The text was updated successfully, but these errors were encountered:
Yeah, I've come around to accepting that this is an issue. We can make some simplifications, as e.g. the lack of legacy code allows us to simply reject cases we don't understand. But overall this will need a lot of design work.
As a prerequisite, we want to validate elements / attributes and throw a hard error when either is unknown. This is because new features are added to HTML all the time, and we can't predict how escaping will work for them.
This would imply some configuration (?) for custom elements. Maybe look at how Clippy does config.
At minimum, we need: ToHtml/ToAttr, ToText (for <title> and <textarea>), ToUrl (for href and <img src>), ToTrustedUrl (for <script src>), ToStyle/ToStyleAttr, ToScript/ToScriptAttr.
Consider whether we need separate traits for "element body" and "attribute value" contexts, or we can get away with one trait for both.
Separate traits let us micro-optimize, as e.g. element bodies don't need to escape quotes.
Is the Url / TrustedUrl distinction necessary? Go templates don't do it.
Consider serde integration for safely embedding JSON.