While I agree that the article overlooks the security aspects of inline scripting[1], we do have content security policy[2] at our disposal using CSP nonce[3] and hash[4] keywords to allow inline script and CSS. On the other hand, the articles ease-of-use argument of inlining doesn't really hold up after factoring in CSP.

In my opinion, it's consideration as unsafe isn't intended literally. It has more to do with:

- The human error aspect of understanding and tightly implementing CSP,

- Separating style and JS into their own files provides some security as is (and allows ignorance of CSP to continue even though it has it's use case here as well).

Now, if your company takes this pretty seriously, they likely require that CSP should be part of your security process already. If that's the case, any use of unsafe inline in your markup will be blocked by default until concrete steps are taken to have nonce or hash in place.

Edit: I did not intend to sound harsh - just wanted to chip in about the nuances about the possibilites we are provided :)

---

[1]: https://web.dev/articles/csp#inline_code_is_considered_harmf...

[2]: https://www.w3.org/TR/CSP/

[3]: https://content-security-policy.com/nonce/

[4]: https://content-security-policy.com/hash/

[5]: https://web.dev/articles/csp#use_case_3_ssl_only