Preserve embedded style and script

[mattesmohr]

This pull request addresses the issue #189. Since > is an essential symbol in JavaScript and CSS, the escaping should be avoided inside Script and Style.

However we should add a warning in the documentation later to highlight the potential the security risk.

[Frizlab]

Given how dangerous this is (potential code injection if a user input is used in the string), maybe we should prevent user input in the string by only accepting a StaticString instead of a String…
An escape hatch could still exist with a name that would remind the dev what they’re doing is dangerous (e.g. init(unsafeStrings:)).

That would be a much stronger help to avoid dangerous code than just a documentation notice that not many people will read (and this not even written yet).

[mattesmohr]

I get what you are saying, but first and foremost, the functionality of Script and Style should be ensured and as you issued correctly that is not the case at the moment.

As of right now, I have been trying different things to help the situation, but I keep coming to the same conclusion.

• We could escape the JS and CSS context and make them safe, but it would also break valid code, which again eliminates the purpose of having Script and Style in the first place. (Let's ignore for now that we could write an analyser/parser to sanitize edge cases.)

• We could introduce something like ESJ, but honestly feels like an overkill.

• We could at least sanitize </script> and </style> to prevent breaking out of the context.

Or we could just give it the benefit of the doubt. At least for the now, until we figure something out. (Ahhh, maybe you were saying exactly that.)

StaticString would hinder dynamic input, right? I haven't used it before, so correct me if I am wrong.

So that would block off users who have already sanitized their code beforehand and know their code is 100% safe?

Maybe I forgot something to mention while writing it xD, I will add it later.

[Frizlab]

StaticString would hinder dynamic input, right?

Yes, exactly.
"Hello \(myAwesomeVar)" is forbidden in a StaticString, you can only do static strings, like "Hello world!".

---

So that would block off users who have already sanitized their code beforehand and know their code is 100% safe?

That’s why I was suggesting an escape hatch:

An escape hatch could still exist with a name that would remind the dev what they’re doing is dangerous (e.g. init(unsafeStrings:)).