You are hereBlogs / rahul's blog / Drupal and Chrome - Refused to execute a JavaScript script. Source code of script found within request

Drupal and Chrome - Refused to execute a JavaScript script. Source code of script found within request


rahul's picture

By rahul - Posted on 05 June 2011

While editing content on a client site last week, I got a rather confusing error in Google Chrome Developer tools:

Refused to execute a JavaScript script. Source code of script found within request.

I was incorporating Google Maps on a page through a Block and the block content had some javascript code in it. But on saving the block, two issues surfaced: 1) I got the above error in Chrome Dev tools console and 2) The Map did not show up on the page.

Some quick Googling revealed that this happens due to XSS check in Google Chrome where Chrome refuses to execute a piece of javascript code in the following sequence of actions:

  1. The user has an input field on the page where s/he can enter and submit content.
  2. The user enters javascript code wrapped in <script> tags and submits the page.
  3. The next page that opens after submission has the exact same javascript on the page.

Chrome considers it an XSS vulnerability which is indeed a fair check to perform by the browser, considering that if it happens when you are normally browsing the web, more often than not, it would indeed be a Cross-Site scripting exploit.

But here in my case, I was myself editing the content on a client site and the javascript was a (valid and safe) part of the content. But Chrome would simply refuse to execute such content upon submitting the content entry form. This happened to me yesterday again while editing another site for another client (which led me to write this blog post).

It was quite annoying for me, because after entering content and clicking "Preview", I did not see my content rendering perfectly because all javascript in the content was being blocked by the XSS filter in Chrome (the content was doing things like using jQuery to start, pause and resume image slideshows). I was not able to Preview my changes because the XSS filter would block all script submitted as part of the content.

One quick solution was to disable XSS filtering by the browser completely by sending a "X-XSS-Protection: 0" header from the server. But it was not desirable to do so (and I would advise against it on public sites) because users (and anonymous users) could submit comments and other content on the site. And while Drupal input formats certainly filter out harmful content when properly configured, it nevers hurts to have an extra layer of security.

The second option is to Save your content in Drupal (whether its a node or block) and after Saving it, refresh that page. When you refresh the page, it would be a normal GET request to the server with no content submitted and hence XSS filter would not kick in.

But this would not help if you want to "Preview" your changes before submitting and saving them. Anytime you content contains <script> tags and you click "Preview" on a form in Drupal, Chrome would not execute the <script> inside the content preview (the html however would render just fine).

So, what's the solution?? Simple, switch to FireFox/IE (or another browser with not such XSS filtering checks) for such content editing which has <script> tags as part of the content :)

Chrome would not allow scripts to be executed in any way if the scripts were submitted on previous page by the user ("X-XSS-Protection: 0" header as mentioned is an undesirable and potentially dangerous header to use on public sites especially).

So the only escape if you do not want to refresh the page after submitting it or you want to Preview it before submitting it is to switch to a different browser for editing such pages/blocks with <script> tags in the content.

 

For instance add a time token as dummy parameter to the javascript call, so that the script call is different each page load.

rahul's picture

Can you please give an example? Please note that I am talking of editing web pages in a CMS where I am entering external <script> references or inline javacript on the page.

I cannot imagine how can I add a time token (in javascript itself, not in PHP), to inline script or external script reference without using javascript itself that would not be filtered by Chrome's XSS checks.

What you have mentioned (if I have understood it correctly) works for cache-busting purposes, but cannot imagine how this would circumvent Chrome's security checks.

Check if your CMS allows to use variables inside the inline script.

rahul's picture

Hi Arthur, you are talking of inline PHP. Yes Drupal allows that (you can turn PHP filter on in Drupal to write inline PHP). In fact, the home page of this site is generated using inline PHP in Drupal CMS itself.

But allowing users to enter PHP code on a website is a security risk. I am sure you would say allowing <script> is also a risk to which I would agree. In my case, only moderators of the site were allowed to write inline <script> for tasks like page-specific slideshows, jquery pop-ups etc.
I am generally very careful in allowing even my moderators to write inline PHP for pages, a mistake can break the whole site or open up significant holes. 

You can also launch Chrome with --disable-xss-auditor to disable this "feature".

rahul's picture

Yupp, thanks for adding that missing piece HenJi...

Post new comment

The content of this field is kept private and will not be shown publicly.
Type the characters you see in this picture. (verify using audio)
Type the characters you see in the picture above; if you can't read them, submit the form and a new image will be generated. Not case sensitive.

Recent comments