Reasons not to in-line critical css

What security issues exist when using inline CSS? I’m not up to date with this stuff.

You’re not alone, I had to Google it myself.

I was was surprised and humbled to see that it has been a thing for at least 3 years.

Good news is it has wide browser support

Why should websites use it?

Content Security Policy (CSP), a tool which developers can use to lock down their applications in various ways, mitigating the risk of content injection vulnerabilities such as cross-site scripting, and reducing the privilege with which their applications execute.

1 Like

[quote=“Mittineague, post:22, topic:234640”]You’re not alone, I had to Google it myself.

I was was surprised and humbled to see that it has been a thing for at least 3 years.
Well, I haven’t used CSP yet but I understand what it does. But this still doesn’t answer my question - in what ways is inline CSS unsafe?

I’m not a malicious hacker so my knowledge is limited.

But my take is that as long as the inline CSS is from the page author, not so much a problem.

If I want to have a mess of

<span class="warning" style="color: #F00"> 

type of tags in my HTML and deal with the troubleshooting and maintainability problems (or go to a forum and get others to do the work :wink:) that’s my problem but AFAIK security isn’t one of the problems.

AFAIK the main risk is injected content that takes advantage of the way browsers deal with various
image: url() styles.

Fetching remote untrusted URLs can pull in stuff that is not what one would want in their page.

<off topic>
Not that I have ever been an untrusted url, but at one time I had trouble with untrusted people hotlinking to my images. I swapped out the images (left the filenames the same) with a giant image that said —

I’m a thief, I steal people’s images and bandwidth!

It took them a while to figure it out, but they eventually stopped.
I have since adjusted the settings on my server to prevent hotlinking.
</off topic>


I am not sure what harm can be done by injecting CSS into a web page by itself but if JavaScript is injected as well then all sorts of nasty things become possible. CSP headers block inlining of both.

I believe that is the problem.
Browsers can call in a file identified as something other than the JavaScript code it contains

I tried putting together an example. but though it worked back in IE6 days, it didn’t inject JavaScript this time.

I know I didn’t configure my Apache to send CSP headers but looking in dev tools showed a file in-page-script.js
and a response header

Content-Security-Policy:script-src 'self' 'unsafe-eval'; object-src 'self';`

A best as I can determine it’s from a content script in the Ember Inspector extension.

I also found this June 2015 SitePoint article

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.