3 ms·
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
by JSR_FDED 1y ago
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?
- ctidd 1y ago> 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”).
- JSR_FDED 1y agoIsn’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?
- sublinear 1y agoUnder 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.
- ctidd 1y agoCSP 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.
- plant-ian 1y agoInline 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#xss_and_resource_loading https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP... edited: tried to fix formatting
- lionelw 1y ago>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_development/Extensions/Performance/JavaScript#optimizing_event_performance https://developer.mozilla.org/en-US/docs/Learn_web_developme... https://developer.mozilla.org/en-US/docs/Learn_web_development/Core/Scripting/Event_bubbling#event_delegation https://developer.mozilla.org/en-US/docs/Learn_web_developme...