Hacker News Reader

Comment by JSR_FDED | Hacker News Reader

Why is this so weirdly prescriptive about inline event handlers?

> Even in a single file, inline event handlers are not a good idea. One button is OK, but what if you had 100 buttons? You'd have to add 100 attributes to the file; it would quickly turn into a maintenance nightmare.

> You should never use the HTML event handler attributes — those are outdated, and using them is bad practice.

It’s a really good explanatory text, and then get surprisingly opinionated.

Similarly, why is an online event handler considered a security risk? I just don’t see the difference between that and using a named function?

View on HN

>Why is this so weirdly prescriptive about inline event handlers?

>> Even in a single file, inline event handlers are not a good idea. One button is OK, but what if you had 100 buttons? You'd have to add 100 attributes to the file; it would quickly turn into a maintenance nightmare.

What's so weird about this? This practice, known as event delegation, has been a known Good Practice for decades. One event listener attached to a common ancestor element of 100 buttons is more memory efficient than 100 event listeners. Even jQuery, which makes it temptingly ergonomic to give 100 buttons an event listener each, prescribes the event delegation pattern in their documentation.

Edit: Sorry I just read the section; now I'm dismayed the MDN article is not prescribing/recommending event delegation. However I did find other MDN articles explaining it:

https://developer.mozilla.org/en-US/docs/Learn_web_developme...

Inline handlers could execute trusted code without user input but in a way that was unintended like this button that hijacks a method of a trusted library and disguises it behind a like button:

  <button onclick="trustedLib.confirmDeleteAccount()">Like</button>

This should be sanitized when the button html is injected into the DOM but CSP provides complementary protection, [1], if sanitizing fails.

[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP...

edited: tried to fix formatting

> Similarly, why is an online event handler considered a security risk? I just don’t see the difference between that and using a named function?

It is a vector for script injection, and should be disallowed with a strong CSP (no “unsafe-inline”).

Isn’t that only the case when the inline code uses untrusted user data somehow?

Inline: alert(“Hello “+userInput) is problematic.

Inline: alert(“Hello there”) isn’t, right?

Under a properly configured CSP, allowing scripts that aren't from the same origin to inject things into the DOM is the problem.

Both of your examples are problematic.

CSP is a defense in depth mechanism which can be (among other capabilities) used to preempt the capability of inline scripts. This mitigates rendering bypasses, in the event that unsafe rendering occurs. For example, imagine you have an insecure markdown renderer, where a user can manage to escape some HTML and inject it into the DOM in a comment thread of some sort. If they can do so, then they can embed JS inside that HTML and get XSS on other users. Adding a rule to disallow all inline scripts mitigates this, assuming the first layer of defense fails.

Reply on news.ycombinator.com