3 ms·

> While HTML offers onclick handlers to buttons, these are often disallowed outside of demos or tutorials due to Content Security Policy (CSP) rules. WTF. Is t

> While HTML offers onclick handlers to buttons, these are often disallowed outside of demos or tutorials due to Content Security Policy (CSP) rules. WTF. Is this for real? This attribute has been around for decades. It used to be the only way to handle events. Can't believe what I'm reading here. All frameworks use a similar construct. What is the actual problem with onclick attribute?

chuckadams 2y ago
> What is the actual problem with onclick attribute? It's a string, so it's basically eval(), and eval gets disabled for all kinds of legit reasons. It often gets disabled along with inline script tags, which shuts down a whole class of XSS attacks -- which maybe your code isn't vulnerable to, but who knows what some random third party markdown renderer might enable? The alternative to on* attributes is addEventListener, which has also been a thing for decades.
- e12e 2y ago
  Thank you for highlighting the difference between onClick and addEventListener - my frontend skills are rusty and I'd forgotten how prevalent the equivalent of eval(some_string) is.
- jongjong 2y ago
  Wow. This is just silly. The issue is executing untrusted JavaScript... Why would the developer put untrusted Javascript inside the onclick handler? If writing vanilla JS, this would basically never happen. The use of onclick is ridiculously widespread too and it's very rarely misused. With that kind of logic, why not disable fetch() calls and all other calls to any backend service? You know, the backend might respond with some untrusted user input which might end up executed as a script (e.g. in a template or something, some frameworks use eval or a dynamic Function)... We need to protect the developer from that risk... All webpages should be static web pages; no untrusted remote data! I mean these arguments don't quite make sense. You can't remove useful functionality which could potentially be misused under the pretext of adding security. By the time you remove all such features, there will be no features left to use at all! You will end up with a very secure brick which does nothing.
  - chuckadams 2y ago
    If you can get over your sputtering moral outrage, you might try looking up things like XSS attacks and how Content-Security-Policy can mitigate it. XSS can have vectors that are more subtle than just raw-echoing back an input field, and CSP is a set of guard rails that can mitigate any potential damage it can do.
    - jongjong 2y ago
      Well I guess it can serve some corporate use cases were most people don't have the skills to identify issues and prefer to have a policy to just blanket ban all. It's a habit in certain large companies to just ban any tool which might potentially be misused. I see the utility but it's disappointing. I hope they don't force it on everyone because the risk vs solution tradeoff is not relevant to most entities who use it.
      - chuckadams 2y ago
        It's not a global browser policy setting, it's something the serving website enables on a per-page basis. HN serves a (somewhat lax) CSP header itself.

chuckadams 2y ago

> What is the actual problem with onclick attribute? It's a string, so it's basically eval(), and eval gets disabled for all kinds of legit reasons. It often gets disabled along with inline script tags, which shuts down a whole class of XSS attacks -- which maybe your code isn't vulnerable to, but who knows what some random third party markdown renderer might enable? The alternative to on* attributes is addEventListener, which has also been a thing for decades.

e12e 2y ago
Thank you for highlighting the difference between onClick and addEventListener - my frontend skills are rusty and I'd forgotten how prevalent the equivalent of eval(some_string) is.
jongjong 2y ago
Wow. This is just silly. The issue is executing untrusted JavaScript... Why would the developer put untrusted Javascript inside the onclick handler? If writing vanilla JS, this would basically never happen. The use of onclick is ridiculously widespread too and it's very rarely misused. With that kind of logic, why not disable fetch() calls and all other calls to any backend service? You know, the backend might respond with some untrusted user input which might end up executed as a script (e.g. in a template or something, some frameworks use eval or a dynamic Function)... We need to protect the developer from that risk... All webpages should be static web pages; no untrusted remote data! I mean these arguments don't quite make sense. You can't remove useful functionality which could potentially be misused under the pretext of adding security. By the time you remove all such features, there will be no features left to use at all! You will end up with a very secure brick which does nothing.
- chuckadams 2y ago
  If you can get over your sputtering moral outrage, you might try looking up things like XSS attacks and how Content-Security-Policy can mitigate it. XSS can have vectors that are more subtle than just raw-echoing back an input field, and CSP is a set of guard rails that can mitigate any potential damage it can do.
  - jongjong 2y ago
    Well I guess it can serve some corporate use cases were most people don't have the skills to identify issues and prefer to have a policy to just blanket ban all. It's a habit in certain large companies to just ban any tool which might potentially be misused. I see the utility but it's disappointing. I hope they don't force it on everyone because the risk vs solution tradeoff is not relevant to most entities who use it.
    - chuckadams 2y ago
      It's not a global browser policy setting, it's something the serving website enables on a per-page basis. HN serves a (somewhat lax) CSP header itself.