On Fri, 16 Jul 2021 at 15:50, Dan Ackroyd <dan...@basereality.com> wrote:
> On Mon, 12 Jul 2021 at 19:57, Craig Francis <cr...@craigfrancis.co.uk> > wrote: > > > the “go-safe-html” library authors decided that > > "the ergonomics of trusting concatenated constants far outweighs the > security concern". > > Go is a quite different programming language to PHP. > Go is different, it's limited to running the check at compile time. That's why I was referencing the “go-safe-html” library. PHP is more dynamic, so we don't need to have the same restrictions (we can allow the developer to concatenate the string, which allows us to support existing code, rather than relying on the library). The current JavaScript equivalent ideas for string literals appear to be > inactive or archived. As noted in the RFC, it's this one: https://github.com/tc39/proposal-array-is-template-object Krzysztof has just confirmed that he’s working on it, and is currently getting it through tc39 (specifically updates related to Realms, a way of executing JavaScript within the context of a new global object, something PHP does not need to worry about). The other JavaScript approach for dealing with trusted types > (https://auth0.com/blog/securing-spa-with-trusted-types/) is even more > different than this proposal. While the article shows some React/Angular code, the focus is on Trusted Types, which works with this concept. It protects unsafe APIs (like innerHTML), where you can create a policy with methods to check/filter values (e.g. forcing the use of DOMPurify). The isTemplateObject method (which checks that a template string was created by the developer) will work with Trusted Types, so you don't need to rely on filtering (unreliable/limited). Craig
