Issues with injecting custom views - CSP(Content Security Policy) errors.

[Dimu Designs]

I've been using InboxSDK to build a custom Chrome Extension that injects custom views (as iframes) into Gmail. Its a CRM tool for a local business. I've been working with this feature (custom views) for months without issue. 

However, over the last few days that seems to have changed. Now I'm getting a series of Content Security Policy(CSP) reports (via google console) that state my scripts violate security policies and the scripts are prevented from executing, rendering the injected page inactive - and I haven't change a line of code. I'm guessing that Google has made changes on their end as this was never an issue for me before. Here's what a typical "report" looks like in the console:

[Report Only] Refused to load the script 'https://code.jquery.com/jquery-3.1.0.min.js' because it violates the following Content Security Policy directive: "script-src 'nonce-XeGmm43CLlcDP9Bz/9HuEQ9IYMc' 'strict-dynamic' 'unsafe-eval' 'unsafe-inline' https:". 'strict-dynamic' is present, so host-based whitelisting is disabled.

 I now get one of these reports for each script embedded in the page. Is there a possible work-around for this?

[Chris Cowan]

You would get that error if you inject a <script> element into the page with the src attribute set. We recommend that you avoid inline javascript in any html you inject into the page from an extension (this also means avoiding onclick attributes in the html, etc) in order to stay compatible with all possible Content Security Policy values that the page may set. As far as we can tell, Gmail has been experimenting with CSP values and increasing its strictness for subsets of users over the last few years.

You can include jquery within your extension and use it from a content script instead of from inline javascript embedded in html.

Some other options:

* Change the <script> element so it has no src property, and instead has jquery's code as the element's text: <script>...all of jquery here...</script>. Chrome extensions are allowed to inject non-remote script tags into the page and bypass the page's Content Security Policy.

* Place your content in an iframe so that your content isn't directly affected by the page's Content Security Policy. In order for Chrome to allow the iframe placement to bypass the page's CSP, the iframe src attribute must point to a file contained within your extension, *not* a remote http/https URL. (That iframe will then be unaffected by the page's CSP and will instead follow your extension's manifest.json's CSP rule, so you can nest a remote iframe inside of that iframe.)

[Dimu Designs]

Thanks for the feedback and advice. I already have my content in an iframe, but I leveraged the "srcdoc" attribute which may be the cause of my issues. I'll be sure to update my script tags accordingly.

[Dimu Designs]

I forgot to ask. How do you reference a file contained in an extension in the iframe's src attribute? "chrome-extension://[extension-id]/[path-to-file] ?

On Wednesday, February 15, 2017 at 9:38:16 PM UTC-5, Chris Cowan wrote:

[Dimu Designs]

Scratch that question I was able to work around the issue.

I've moved all the 3rd party code libraries used by the injected page into the extension and listed then in the manifest under the "web_accessible_resources" section. I later reference them on the page (see documentation) as follows:
<script src="chrome-extension://[PACKAGE ID]/[PATH]">...</script>

[Chris Cowan]

You should use chrome.runtime.getURL('filename.png') to get a chrome-extension:// URL pointing to a file within your own extension.

[Chris Cowan]

Here's an example of a generic iframe and supporting code an extension can use to do the iframe-in-iframe trick for getting around the host page CSP: https://gist.github.com/AgentME/9f8b3c9f4e671d4e422bd34901ff882f