Angular-cli: Making angular-cli work with strict CSP?

Created on 6 Dec 2016  路  21Comments  路  Source: angular/angular-cli

Please provide us with the following information:

OS?

Windows 7

Versions.

angular-cli: 1.0.0-beta.21
node: 6.6.0
os: win32 x64
chrome: 54.0.2840.99 m (64-bit)

Repro steps.

  1. Run ng new csp-test
  2. Add the following meta tag to index.html:
    <meta http-equiv="Content-Security-Policy" content="default-src 'none'; script-src 'self'; style-src 'self'; img-src 'self'; connect-src 'self' ws://localhost:4200; font-src 'self';">
  3. Run ng serve -aot
  4. Open localhost:4200 in chrome

The log given by the failure.

The following errors show up in the Chrome debugger console:

Refused to apply inline style because it violates the following Content Security Policy directive: "style-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='), or a nonce ('nonce-...') is required to enable inline execution.
insertStyleElement @ addStyles.js:115

Refused to apply inline style because it violates the following Content Security Policy directive: "style-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-xylbkVtqJQuRDTD/O50Zkbb0PJR006+vxsulnu5EOD4='), or a nonce ('nonce-...') is required to enable inline execution.
applyToTag @ addStyles.js:225

Refused to apply inline style because it violates the following Content Security Policy directive: "style-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='), or a nonce ('nonce-...') is required to enable inline execution.
DomSharedStylesHost._addStylesToHost @ shared_styles_host.js:55

Mention any other details that might be useful.

Is there any way to make angular2 with angular-cli work with a strict Content Security Policy? I realize I can add 'unsafe-inline', but that defeats a lot of the purpose of CSP.

Most helpful comment

@hansl It would be wonderful if we could create secure apps with angular cli. Which version do you think could address this?

All 21 comments

I don't think there is a way to completely avoid unsafe-inline for styles. And if you define any scripts in angular-cli.json, you'll also need `unsafe-eval' unfortunately.

These are limitations of webpack, unfortunately. The styles get loaded in the JavaScript bundle by Webpack and injected in the header.

I'm going to close this working as intended. It's unfortunate but this won't be fixed for the final version, and you'll need to loosen the restrictions for CSP.

We will revisit this when we start working on the next version of the CLI.

+1

@hansl It would be wonderful if we could create secure apps with angular cli. Which version do you think could address this?

+1

+1

If you use 'nonce' or run a task (gulp or grunt) that calculates the SHA of the script, it is a way to solve this problem. However, there is another similar problem: blocking the 'eval'. This one does not have artifacts similar to 'inline-script'

I just opened a new issue for the latest version of Angular CLI to allow it to build without eval and Function: https://github.com/angular/angular-cli/issues/6872

I suppose the issue is still open. Is it expected to be resolved in next Angular release? For the moment, I am using unsafe-eval and unsafe-inline iin my CSP to make the code work.

unsafe-eval is no longer required if using a production build (with the reflect polyfills removed as they are only needed for JIT).

unsafe-inline is still required for styles. If that's not acceptable for the project's requirements, the other option is to only use global styles in the application and to not use any Angular libraries which contain component styles. Note that the project will lose full benefits of the component-based architecture under this scenario.

For a project of ours, we'll need to mitigate all unsafe-inlines as well. Will this be possible in a future angular release?

Hi, Is there any update on this issue, or are we left with no CSP for the time being?

@clydin Is it not possible to output all possible inline styles into a single css file so that 'unsafe-inline' can be removed? Many organizations (especially enterprise) require no 'unsafe-inline', and using only global styles is not a good option (it goes against Angular philosophy/project structure/workflow). Frankly, if that's the only option, I would drop Angular and choose a different framework for a web app.

I would hope the team is still considering this issue.

We will revisit this when we start working on the next version of the CLI.

@hansl Have we reached the next version of the CLI yet? Is there another open issue for this?

Since the angular-cli is pretty locked in and hard to extend, I feel it is crucial that we have an option to generate CSP Hash data at build time.

Something like this from slack.
https://github.com/slackhq/csp-html-webpack-plugin

Without this, we would need to run another tool after the angular build that obtains hashes of all of the files

@blowsie is there a reason you would need the hashes for the files?

A CSP configuration similar to the following should work for a new project with material. This would of course need to be adjusted for a project's specific needs and requirements.
(broken into multiple lines for clarity)

default-src 'none';
script-src 'self';
style-src 'self' 'unsafe-inline' https://fonts.googleapis.com;
img-src 'self';
connect-src 'self';
font-src https://fonts.gstatic.com

@clydin using hashes prevents script execution of modified files, which could protect in many scenarios, including public machines.

Without hashing with the script could be modified and and you could be none the wiser.

That is Subresource Integrity (SRI) not CSP. This is already supported within the CLI by using the subresourceIntegrity option.

It is typically used when files are stored by a third-party and authenticity is required. Generally if the files are self hosted and HTTPS is used, an attacker would need access to the server. And in which case they could also modify the hashes as well. However, as an extra layer of protection, it doesn't have much downside.

@clydin Any chance we could get that extra layer of protection so that we can also avoid using unsafe-inline for styles?

Webpack does support generation of nonce for inline tags, can't this be supported in AngularCLI? https://github.com/webpack/webpack/pull/3210

Added https://github.com/angular/angular-cli/issues/12378 for request to add nonce support that would address this issue.

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_This action has been performed automatically by a bot._

Was this page helpful?
0 / 5 - 0 ratings