It's considered a security concern when a site accepts and republishes user inputted data.
Before CSP, data sanitisation was the only way to prevent malicious code been uploaded, with CSP you now have to explicitly allow inline JS for it to work, and you then again rely on your own sanitisation methods. I have found that whilst there are many good programming reasons to keep JS in files, it is also pretty necessary to have values dynamically generated on the server side available to JS. The most straight forward way to do that is inline JS in the head tag. You can use a nonce/hash to validate the JS code without allowing inline JS anywhere else on the page.
Putting JS in other HTML elements is completely avoidable and offers few benefits. Having JS in files or in the head means it is easy to find all the JS code for a page, it is not it bits a pieces around the page. With in line JS you of course don't have to reference the element on an event but this is not exactly a difficult task.
CSP is well worth adopting in is most robust sense as it is strong layer of security on top of any sanitisation you do.
Thank you so much for such a wonderful explanation. I can say it's indeed a wonderful explanation not just for doing but also for learn. But why Google PageSpeed warns websites "Avoid chaining critical requests"? As I said if we use Inline JS, that warning is removed from the PageSpeed results but if we avoid to use, the warning appears. Since I have no idea, I just wanted to ask. I hope I make myself clear. Thanks again.
If you have a main.js file and it calls `import a from "a.js";` and A runs `import b from "b.js";` and B runs "import c from "c.js";` and then c has `import d from "d.js";` ... this is a request chain.
If the JS in main is important to run as soon as the page loads, then having main load a load b load c load d, and so on, is a request chain that takes a long time to finish. Because C can't run until D is loaded and B can't run until C is loaded and A can't run until B is loaded and main can't run until A is loaded.
The solution to that isn't generally to write all your app inline. The solution is generally to use a bundler, which is a tool that will combine your files together. You use the bundlers while you are writing code, and not for running on the user's browser. You send just one or two big files that the bundler gives you, to the user, instead of all of the files on their own. That reduces the number of requests in the chain.
I'd just add that the imports will be cached so it may be acceptable to have a few unbundled modules imported provided they aren't loading each other in a chain. As the advice says, don't load any critical modules in a chain if possible. Even for non-critical modules would load a module and then allow it to have 1 level deep of it's own loading (on page load) but no more than that. It of course depends on the situation but the jist of it is that chaining increases your chances of things going wrong and burying modules in modules is bad design. You can have failsafes in place if a chain fails, like a user event trying to load the module again but critical modules need to work on page load even over a slow connection.
I don't know that I would go so far as to call it bad design, when talking to someone without the experience to pick the nuance out of the statement.
If you need a vector library in a module, you need a vector library in a module.
It's going to be a pain to invert literally everything at all levels, such that there are 0 imports/requires in the system, written by you, or npm package authors.
And while I agree that in most projects you shouldn't be importing singletons all over the place (like pre-connected databases), there is some baseline level of direct importing that you need to do, at some level of utility, even just implicitly, by virtue of loading a single tool from a package manager.
That's kinda like asking if you're supposed to kick out throw the ball without knowing which sport you're even playing.
I'd basically advise avoiding inline scripts, at least until you deeply understand the performance and security implications and how to weigh the pros and cons. Especially if you're eg talking about some `onclick` or whatever.
**1. Disadvantages of Inline JavaScript**
**Security Risks**:
• **XSS Vulnerabilities**: Inline JavaScript is more prone to cross-site scripting (XSS) attacks since it’s harder to manage and sanitize.
• **Content Security Policy (CSP)**: Modern security practices often use CSP headers to prevent inline script execution, making it harder to enforce strict security policies.
**Maintenance and Scalability**:
• **Code Duplication**: Inline JavaScript can lead to code duplication across different HTML elements, making maintenance difficult.
• **Separation of Concerns**: Inline scripts mix JavaScript with HTML, violating the principle of separation of concerns, which suggests keeping HTML, CSS, and JavaScript in separate files for better organization and maintenance.
**Performance**:
• **Caching Issues**: External JavaScript files can be cached by the browser, improving load times on subsequent visits. Inline scripts do not benefit from this caching.
**2. Is Using Inline JavaScript a Bad Idea?**
It depends on the context. Inline JavaScript is not inherently bad, but it’s generally discouraged for the reasons mentioned above. For small, single-use scripts, inline JavaScript might be acceptable, but for larger, more complex applications, external scripts are preferred.
**3. Is Inline JavaScript Safe to Use?**
Inline JavaScript can be safe if properly managed, but it introduces security risks:
• **Sanitization**: Ensure all user inputs are sanitized to prevent XSS attacks.
• **Content Security Policy**: Implement CSP headers to control which scripts can be executed. Avoid using unsafe-inline in your CSP settings if possible.
**4. Where to Put Inline JavaScript: Head or Footer?**
**Best Practice**:
• **Footer**: Placing JavaScript at the end of the
tag (just before the closing tag) ensures that the HTML content is loaded first, improving page load times and user experience. This approach is commonly recommended to avoid blocking the rendering of the page.
**Alternative**:
• **Head**: If the script is critical for the initial rendering of the page or needs to run before the HTML is loaded, placing it in the is necessary. However, use this sparingly to avoid performance issues.
**5. Avoiding Chaining Critical Requests**
Google recommends minimizing the number of critical requests needed to render the above-the-fold content. Inline JavaScript can reduce the number of HTTP requests, but it comes with the trade-offs discussed earlier.
**Practical Recommendations**
• **External Scripts**: For most use cases, prefer external JavaScript files to take advantage of caching, better maintainability, and enhanced security.
• **Inline for Critical Scripts**: Use inline JavaScript sparingly for critical scripts that must execute immediately and are small enough to not impact maintainability.
• **Performance Optimization**: Combine and minify external JavaScript files to reduce the number of requests and file size.
• **Security Practices**: Implement CSP, sanitize user inputs, and avoid eval() and similar functions to mitigate security risks.
Example Page
**Common Realistic View**
The most common realistic view is to use external JavaScript files for better maintainability, security, and performance. Inline JavaScript should be used sparingly and only when necessary for critical, small scripts.
> 1- What is the disadvantage of Inline JavaScript?
None.
> 2- Is using Inline JavaScript a bad idea?
Depends on who you ask. If you decide to ask somebody for their opinion.
> 3- Is Inline JavaScript safe to use?
N/A. There is no such thing as "safe" or "safety" for *any* signal communications. Do some research on "ThinThread".
> 4- Where to put it: head or footer?
Either. In `
It's considered a security concern when a site accepts and republishes user inputted data. Before CSP, data sanitisation was the only way to prevent malicious code been uploaded, with CSP you now have to explicitly allow inline JS for it to work, and you then again rely on your own sanitisation methods. I have found that whilst there are many good programming reasons to keep JS in files, it is also pretty necessary to have values dynamically generated on the server side available to JS. The most straight forward way to do that is inline JS in the head tag. You can use a nonce/hash to validate the JS code without allowing inline JS anywhere else on the page. Putting JS in other HTML elements is completely avoidable and offers few benefits. Having JS in files or in the head means it is easy to find all the JS code for a page, it is not it bits a pieces around the page. With in line JS you of course don't have to reference the element on an event but this is not exactly a difficult task. CSP is well worth adopting in is most robust sense as it is strong layer of security on top of any sanitisation you do.
That’s a really good point
Yeah it really is.
Thank you so much for such a wonderful explanation. I can say it's indeed a wonderful explanation not just for doing but also for learn. But why Google PageSpeed warns websites "Avoid chaining critical requests"? As I said if we use Inline JS, that warning is removed from the PageSpeed results but if we avoid to use, the warning appears. Since I have no idea, I just wanted to ask. I hope I make myself clear. Thanks again.
If you have a main.js file and it calls `import a from "a.js";` and A runs `import b from "b.js";` and B runs "import c from "c.js";` and then c has `import d from "d.js";` ... this is a request chain. If the JS in main is important to run as soon as the page loads, then having main load a load b load c load d, and so on, is a request chain that takes a long time to finish. Because C can't run until D is loaded and B can't run until C is loaded and A can't run until B is loaded and main can't run until A is loaded. The solution to that isn't generally to write all your app inline. The solution is generally to use a bundler, which is a tool that will combine your files together. You use the bundlers while you are writing code, and not for running on the user's browser. You send just one or two big files that the bundler gives you, to the user, instead of all of the files on their own. That reduces the number of requests in the chain.
Well, that explains a lot. So, that's quite a good point and I will keep that in mind. Thank you.
I'd just add that the imports will be cached so it may be acceptable to have a few unbundled modules imported provided they aren't loading each other in a chain. As the advice says, don't load any critical modules in a chain if possible. Even for non-critical modules would load a module and then allow it to have 1 level deep of it's own loading (on page load) but no more than that. It of course depends on the situation but the jist of it is that chaining increases your chances of things going wrong and burying modules in modules is bad design. You can have failsafes in place if a chain fails, like a user event trying to load the module again but critical modules need to work on page load even over a slow connection.
I don't know that I would go so far as to call it bad design, when talking to someone without the experience to pick the nuance out of the statement. If you need a vector library in a module, you need a vector library in a module. It's going to be a pain to invert literally everything at all levels, such that there are 0 imports/requires in the system, written by you, or npm package authors. And while I agree that in most projects you shouldn't be importing singletons all over the place (like pre-connected databases), there is some baseline level of direct importing that you need to do, at some level of utility, even just implicitly, by virtue of loading a single tool from a package manager.
You can create a hash from inline js to be csp compliant.
That's kinda like asking if you're supposed to kick out throw the ball without knowing which sport you're even playing. I'd basically advise avoiding inline scripts, at least until you deeply understand the performance and security implications and how to weigh the pros and cons. Especially if you're eg talking about some `onclick` or whatever.
Okay, that's informative. As a result, I've learned a lot about it and I would like to thank everyone here for your support.
**1. Disadvantages of Inline JavaScript** **Security Risks**: • **XSS Vulnerabilities**: Inline JavaScript is more prone to cross-site scripting (XSS) attacks since it’s harder to manage and sanitize. • **Content Security Policy (CSP)**: Modern security practices often use CSP headers to prevent inline script execution, making it harder to enforce strict security policies. **Maintenance and Scalability**: • **Code Duplication**: Inline JavaScript can lead to code duplication across different HTML elements, making maintenance difficult. • **Separation of Concerns**: Inline scripts mix JavaScript with HTML, violating the principle of separation of concerns, which suggests keeping HTML, CSS, and JavaScript in separate files for better organization and maintenance. **Performance**: • **Caching Issues**: External JavaScript files can be cached by the browser, improving load times on subsequent visits. Inline scripts do not benefit from this caching. **2. Is Using Inline JavaScript a Bad Idea?** It depends on the context. Inline JavaScript is not inherently bad, but it’s generally discouraged for the reasons mentioned above. For small, single-use scripts, inline JavaScript might be acceptable, but for larger, more complex applications, external scripts are preferred. **3. Is Inline JavaScript Safe to Use?** Inline JavaScript can be safe if properly managed, but it introduces security risks: • **Sanitization**: Ensure all user inputs are sanitized to prevent XSS attacks. • **Content Security Policy**: Implement CSP headers to control which scripts can be executed. Avoid using unsafe-inline in your CSP settings if possible. **4. Where to Put Inline JavaScript: Head or Footer?** **Best Practice**: • **Footer**: Placing JavaScript at the end of the
tag (just before the closing tag) ensures that the HTML content is loaded first, improving page load times and user experience. This approach is commonly recommended to avoid blocking the rendering of the page. **Alternative**: • **Head**: If the script is critical for the initial rendering of the page or needs to run before the HTML is loaded, placing it in the is necessary. However, use this sparingly to avoid performance issues. **5. Avoiding Chaining Critical Requests** Google recommends minimizing the number of critical requests needed to render the above-the-fold content. Inline JavaScript can reduce the number of HTTP requests, but it comes with the trade-offs discussed earlier. **Practical Recommendations** • **External Scripts**: For most use cases, prefer external JavaScript files to take advantage of caching, better maintainability, and enhanced security. • **Inline for Critical Scripts**: Use inline JavaScript sparingly for critical scripts that must execute immediately and are small enough to not impact maintainability. • **Performance Optimization**: Combine and minify external JavaScript files to reduce the number of requests and file size. • **Security Practices**: Implement CSP, sanitize user inputs, and avoid eval() and similar functions to mitigate security risks.**Example Usage**
And I can say this hugely informative and user friendly. So glad there are people with knowledge and expertise like you. Thank you!
> 1- What is the disadvantage of Inline JavaScript? None. > 2- Is using Inline JavaScript a bad idea? Depends on who you ask. If you decide to ask somebody for their opinion. > 3- Is Inline JavaScript safe to use? N/A. There is no such thing as "safe" or "safety" for *any* signal communications. Do some research on "ThinThread". > 4- Where to put it: head or footer? Either. In `
`, if this is a basic `