Menu
Currently I'm defining Content Security Policy (CSP) as below;
Header set Content-Security-Policy: "default-src 'self' data:; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data:;" Considering the CSP definition above, I have a challenge with inline JavaScript as it can be over-ridden at any time.
What is the use of unsafe-inline if it virtually does not protect?
705
The unsafe-inline option is to be used when moving or rewriting inline code in your current site is not an immediate option but you still want to use CSP to control other aspects (such as object-src, preventing injection of third-party js etc.).
'unsafe-eval' allows the application to use the eval() JavaScript function. This reduces the protection against certain types of DOM-based XSS bugs, but makes it easier to adopt CSP. If your application doesn't use eval() , you can remove this keyword and have a safer policy.
CSP is a browser security mechanism that aims to mitigate XSS and some other attacks. It works by restricting the resources (such as scripts and images) that a page can load and restricting whether a page can be framed by other pages.
Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross-Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft, to site defacement, to malware distribution.
The unsafe-inline option is to be used when moving or rewriting inline code in your current site is not an immediate option but you still want to use CSP to control other aspects (such as object-src, preventing injection of third-party js etc.). You are correct in that unsafe-inline does not offer much security as it allows execution of unsafe in-page scripts and event handlers.
Google's CSP Evaluator is a nifty tool to determine if your policy is strong.
A use case where the unsafe-inline option is used can be found in Google's Web Developer documentation on Content Security Policy:
A wedding-ring discussion forum admin wants to ensure that all resources are only loaded via secure channels, but doesn't really write much code; rewriting large chunks of the third-party forum software that's filled to the brim with inline script and style is beyond his abilities. The following policy would be effective:
Content-Security-Policy: default-src https:; script-src https: 'unsafe-inline'; style-src https: 'unsafe-inline'Even though
https:is specified indefault-src, the script and style directives don't automatically inherit that source. Each directive completely overwrites the default for that specific type of resource.
165
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
