2

I'm developing a chrome extension that renders and sidebar iframe in Gmail.

A while back, we ran into a Content Security Policy issue that broke our extension and ran into a well-known error that shows up in your console as

Refused to frame '[OUR DOMAIN]' because it violates the following Content Security Policy directive: ...

To fix it, we had to rewrite the CSP header as explained in this blog post.

However, recently, we've been getting the same error, even after having implemented the fix suggested in the blog post.

enter image description here

As you can see, even though we added the chrome.webRequest.onHeadersReceived listener to overwrite the CSP header, our domain doesn't seem to be working. As a result, our sidebar does not load.

Notes and attempts:

  • Note that upon refreshing the entire page, the sidebar will sometimes load successfully %50 of the times, which leads me to believe that we're not adding the above event listener fast enough. To solve this, I pulled the event listener out of our background class and placed it at the top of the background js script. However, this issue seems to still persist.

  • We've tried to remove and re-add the extension but that didn't yield any permanent results.

  • Throughout testing, I also noticed that adding another extension that implements a similar override on the CSP header will cause our extension to break. Removing and re-adding our extension brings us back to the 50-50 issue in the first note.

[Update]

  • It seems that being able to reproduce it %50 of the times has to do with the version of chrome. After upgrading it to 72, I'm now able to reproduce the issue. However, doing a hard refresh on the page will sometimes allow the page to load.

  • More details on our setup: What we do is basically have a background.html which contains html templates and we have one template that contains an iframe tag. To get the template with the iframe, we do a sendMessage, grab the response, which is the template in string, convert it to DOM element via jquery, append it to body, and change the iframe's src attribute. What happens is the iframe loads fine initially, but when you click on any link in the iframe that would redirect to another page, the same error above shows up.

I can provide snippets and more info if needed.

Jack
  • 441
  • 3
  • 13
  • 2
    As you can see in the documentation for webRequest API, the winner in a race of overrides is totally unpredictable. I suggest reworking the code so that you don't load any scripts from third-party domains at all (usually it's a bad idea anyway), instead put as much as possible into your content script, or into an iframe element added to gmail page that points to a html file inside your extension (exposed via web_accessible_resources) where you draw your main UI, sidebars, whatever. Inside that iframe you'll be able to have another iframe that points to your custom domain. – wOxxOm Feb 21 '19 at 16:45
  • Hi @wOxxOm. I added "More details on our setup" to explain our situation. We basically try to inject an iframe and manipulate the src. This worked until not too long ago. I believe what you're suggesting is somewhere along the lines of [this type of rework](https://stackoverflow.com/questions/24641592/injecting-iframe-into-page-with-restrictive-content-security-policy) right? Do you have any suggestions that do not require that sort of rework? I'm asking because reworking may not necessarily be an option for us. – Jack Feb 23 '19 at 01:38
  • Try disabling chrome://flags/#network-service and btw I suggest parsing html with DOMParser API. – wOxxOm Feb 23 '19 at 04:38
  • Thanks @wOxxOm. It looks like it was an issue for their previous version of Chrome 72. They just released a patch for it. Our extension is now working. – Jack Feb 25 '19 at 15:40
  • Hi @Jack Im facing a similar issue on chrome 81, In my scenario also I'm rewriting CSP and x-frame-options headers using chrome.webRequest.onHeadersReceived listener. This works well in chrome v80 and below. Are you facing the same issue in v81 again? – udarakr Apr 30 '20 at 15:42

0 Answers0