I think the problem is that if you allow inline scripting (or inline CSS) a script can’t be prevented from loading from another domain, so in order to implement a same origin policy, CSP rules normally block inline scripts & CSS. I suspect we don’t have any CSP rules being imposed by the browser at present, but have not checked that.
When testing websites with the early SAFE Beaker Browser inline scripts & CSS were disabled for same origin security, but I think this was imposed by the web proxy which has since been removed, so that may be why it is no longer active.
What I’m not sure about is whether it is still needed or not. So that’s really my question - have we left a security hole open, or is this no longer a risk?
I suspect it is a risk, but that it is (like the current Web) up to the website to provide appropriate CSP headers. However, my understanding is that the main browsers are taking on that responsibility by gradually imposing ever stricter CSP rules because so few websites are set up adequately in this regard. In which case we should probably have SAFE Browser do the same.
So my hunch is that we will need to close this loophole or we risk leaving users open to using websites and apps that are at risk from attacks such as XSS (eg inserting HTML into comments, forum posts etc).
