aws-samples/cloudfront-authorization-at-edge

Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self'

pandrel opened this issue · 3 comments

pandrel commented

Deploying this to a working cloudfront distribution is causing inline javascript to fail. HTML page renders properly but javascript code does not. All scripts are local to the s3 bucket not from any external urls. Any help is much appreciated.

Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self' https://code.jquery.com https://stackpath.bootstrapcdn.com". Either the 'unsafe-inline' keyword, a hash ('sha256-sSYP07KSXyZ0gQue3jDWS5nZaWUz7V/V0566xsjP90k='), or a nonce ('nonce-...') is required to enable inline execution.

ottokruse commented

Hi @pandrel

The default HTTP headers that this solution sets include a quite strict CSP––which seems to hinder you:

HttpHeaders:
    Type: String
    Description: The HTTP headers to set on all responses from CloudFront. To be provided as a JSON object
    Default: >-
      {
        "Content-Security-Policy": "default-src 'none'; img-src 'self'; script-src 'self' https://code.jquery.com https://stackpath.bootstrapcdn.com; style-src 'self' 'unsafe-inline' https://stackpath.bootstrapcdn.com; object-src 'none'; connect-src 'self' https://*.amazonaws.com https://*.amazoncognito.com",
        "Strict-Transport-Security": "max-age=31536000; includeSubdomains; preload",
        "Referrer-Policy": "same-origin",
        "X-XSS-Protection": "1; mode=block",
        "X-Frame-Options": "DENY",
        "X-Content-Type-Options": "nosniff"
      }

The easiest way to get going fast: redeploy the stack again (causing a stack update), this time provide the value "{}" for parameter "HTTPHeaders". This effectively removes the default HTTP headers.

The right way forward: determine which CSP headers you need exactly, and pass those in as HTTPHeaders.

Let me know if that helps.

pandrel commented

You are awesome. I updated the stack by adding 'unsafe-inline' in the script-src section, reconfigured cloudfront behaviors with new version of the lambda and everything worked fine.
FYI .. i am using existing cloudfront distribution so had to manually update the behaviors.

Thanks so much for your help. !!!

rpattcorner commented

In case anybody comes across this, here are two header sets you can feed to the CFN stack that I've found useful until you can develop a real working CSP.

#1 - this set puts CSP in report-only mode. It will moan about every violation, but still let you run. Very useful in the process of tracking down problems on the way to a valid CSP. Provides no CSP protection.

{
  "Content-Security-Policy-Report-Only": "default-src 'none'; img-src 'self'; script-src 'self'; style-src 'self'; object-src 'none'; connect-src 'self' https://*.amazonaws.com https://*.amazoncognito.com",
  "Strict-Transport-Security": "max-age=31536000; includeSubdomains; preload",
  "Referrer-Policy": "same-origin",
  "X-XSS-Protection": "1; mode=block",
  "X-Frame-Options": "DENY",
  "X-Content-Type-Options": "nosniff"
}

#2 This policy has no CSP but retains other important security items like transport security, referrer policy, etc. No CSP protection, no report warnings:

{
  "Strict-Transport-Security": "max-age=31536000; includeSubdomains; preload",
  "Referrer-Policy": "same-origin",
  "X-XSS-Protection": "1; mode=block",
  "X-Frame-Options": "DENY",
  "X-Content-Type-Options": "nosniff"
}
  • 👍8