Item12701: Foswiki has inline CSS and JS which breaks usage of Content-Security-Policy

When setting a strict Content-Security-Policy HTTP Header (http://en.wikipedia.org/wiki/Content_Security_Policy)

eg in Apache: Header set Content-Security-Policy "default-src 'self'"

you get:

Refused to apply inline style because it violates the following Content Security Policy directive: "default-src 'self'". Note that 'style-src' was not explicitly set, so 'default-src' is used as a fallback.
view:230

This is as FosWiki has inline CSS.

It would be great if inline-CSS was not used as then a full CSP policy can be defined which avoids a variety of XSS attacks. This would require moving away a variety of \<style\> statements out of the main output to separate .css files.

The tricky part likely is for color changes for text, one way to solve that is to define col-##### in a generated .css file and reference these. One could even do this for all statements, thus making foswikiGenNUMBER, for each style. Not easy, not very pretty, but better than having somebody XSS you...

-- JeroenMassar - 19 Dec 2013

True. There are some more cases which block a stricter content security policy:

• use of eval to parse json in jquery.metadata module .... switching it to $.parseJSON() however breaks a few other cases as parseJSON is stricter with regards to its syntax requirements than eval()
• JQueryPlugin propagates Foswiki preference settings using inline javascript ... (similar to drupal).

-- MichaelDaum - 22 Apr 2014

I take it that the 2 checkins moving some inline css to a file are not the complete solution here? Is this anything we can complete for 1.2? Okay to release as is?

-- GeorgeClark - 08 Jan 2015

This is probably a never ending battle from the point where we are atm. Things checked in so far are only a starting point that more plugins and wiki apps have to follow up to.

-- MichaelDaum - 08 Jan 2015

Commenting is disabled while not logged in