I like the fact that the Closure library has those, but those are optional.

We have our own mechanisms already in our private libraries because the Royale 
SDK had no consideration for it.  Security should not be an afterthought, and 
by not defaulting to having some form of security baked in by default we are 
contributing to the global problems of it.  We cannot expect newer developers 
to follow things like OWASPs top [1], and they will not see a need for it until 
there is an incident.

[1] https://owasp.org/www-project-top-ten/


-Mark K

-----Original Message-----
From: Harbs <harbs.li...@gmail.com>
Sent: Thursday, December 9, 2021 11:13
To: dev@royale.apache.org
Subject: [Non-DoD Source] Re: 0.9.9

I just went poking around and I found that Google Closure has a pretty 
extensive library for sanitizing HTML: 
https://github.com/google/closure-library/tree/master/closure/goog/html/sanitizer

Considering we’re already using the goog libs for other things, it should be 
fairly straight-forward to wrap the functionality in Royale classes. Feel free 
to work on that… ;-)

I do think that the sanitizing should be opt-in.

Harbs

> On Dec 9, 2021, at 5:03 PM, Kessler CTR Mark J 
> <mark.kessler....@usmc.mil.INVALID> wrote:
>
>    I am on the opposite spectrum of this opinion. We had to write our own 
> library on-top of the basic Royale for our applications that was more 
> security minded.  All of our defaults are for innerText as it will not 
> interpret the contents or use new variants that already have security built 
> it such as a textarea's "value" has security considerations by default now. 
> This is important as cybersecurity teams or software tests can easily show 
> basic XSS in fields either reflected or stored.  Remember the end users are 
> the ones that are directly affected by vulnerabilities built into a web 
> application and a developer that does not follow good sanitization practices 
> will surely allow easily preventable vulnerabilities in.
>
>   We should always have secure defaults, but allow developers to violate good 
> security practices on their own as a conscious decision.
>
>
> -Mark K

Reply via email to