Open farrago opened 8 years ago
I should mention that the default templates also use inline styles which will cause CSP violations.
For a fully CSP-compliant result you will also have to use your own replacement templates that don't use inline styles and instead set the styling through your application's own CSS.
Summary
Inline styles are not allowed under CSP, so this replaces the inline styles used by
$modalStack
with calls toangular.element.css()
Details
$modalStack.open
creates two divs directly with angular.element, and both divs have inline style elements (i.e.'<div style="...">'
).If Content Security Policy (CSP) is enabled, these inline styles cannot be applied and cause errors. e.g. in chrome:
This is fixed by replacing the inline styles with calls to
angular.element.css()
(which boils down toHTMLElement.style.foo = bar;
) as this does not trigger the inline styles violation.modal-window
, it is a bit more complex:modal-window
directive replaces it because Angular merges the attributes of the temp div and the new one. The temp div has an inline style (set by .css()), and trying to apply thisstyle='...'
as an attribute to the new div causes the same inline execution error.mm-top
), then themodal-window
applies the value to itself usingelement.css()
.Setup
Browser: Chrome
52.0.2743.116 m
(up to date), plus same result in Firefox, Edge, etc. OS: Windows 10 Server: NodeJS 4.4.3 CSP Headers:content-security-policy-report-only: default-src 'self'; report-uri /api/v0/csp-report
(This reports but doesn't prevent violations of the policy while debugging rules).Notes
As per the error reported by Chrome, this could theoretically be worked around by using
'unsafe-inline'
but this is, as named, unsafe. It could also be worked around with a hash for each case but that isn't well supported by browsers yet, and there are a lot of different cases that would need a hash for each one. Nonces are even harder to use with library code.Test Plan: