This article is a part of our Web Security Knowledge Base (back to index)
Why CSP Scanner: style-src unsafe-inline can be dangerous
Content Security Policy (CSP) adds a layer of security which helps to detect and mitigate certain types of attacks such as Cross Site Scripting (XSS) and data injection attacks. Hackers use XSS attacks to trick trusted websites into delivering malicious content. The browser executes all code from trusted origin and can’t differentiate between legitimate and malicious code, so any injected code is executed as well.
The ‘style-src’ directive specifies valid sources for stylesheets. The ‘unsafe-inline’ allows the use of inline resources, such as inline ‘<script>’ and ‘<style>’ elements, ‘javascript:’ URLs and inline event handlers. This means that any places where a user can inject a style attribute into your website, they can also modify the DOM of your page. In worst cases the attacker is able to carefully prepare styles in order to send any information present on the page to external domains and expose them or use the data in a malicious way.
How to fix CSP Scanner: style-src unsafe-inline
Ensure that your web server, application server, load balancer, etc. is properly configured to set the correct Content-Security-Policy header.
You can prevent the data being leaked despite using the ‘unsafe-inline’ by providing other CSP rules to be correct and to never allow any untrusted requests or wildcard domain.
How does ScanRepeat report CSP Scanner: style-src unsafe-inline
ScanRepeat gets the ‘Content-Security-Policy’ header of every HTTP response and checks whether it contains the ‘unsafe-inline’ value for the ‘style-src’ directive. It reports every URL that the ‘unsafe-inline’ occurred in the response.
Would you like to test your application now against this problem? Sign up for our free trial
Scan Your Web App Now