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.