82

In WebKit I get the following error on my JavaScript:

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

The code is for a JavaScript spinner, see ASCII Art.

The code used to work OK and is still working correctly in Camino and Firefox. The error only seems to be thrown when the page is saved via a POST and then retrieved via a GET. It happens in both Chrome/Mac and Safari/Mac.

Anyone know what this means, and how to fix this?

Zoe
  • 27,060
  • 21
  • 118
  • 148
doekman
  • 18,750
  • 20
  • 65
  • 86
  • Hmm, probably my WebKit has been updated. The page works again. Also all old revisions of the page (see Old Revisions button on the bottom of the page). – doekman Oct 11 '09 at 13:59
  • this error occurs in the tryit editor of w3schools http://www.w3schools.com/js/tryit.asp?filename=tryjs_events the script is executed the first time, but it's blocked from the moment you click on the "edit and click me" button. –  May 10 '11 at 20:20
  • 1
    If you press the "edit and click me" button, the content of the textarea (with the javascript) is sent to the server via a POST. Chrome detects javascript is posted to the server and it might be malicious. The blocking is the measure against XSS attacks. – doekman May 11 '11 at 08:59
  • Here's link that shows how to set the header X-XSS-Protection: http://stackoverflow.com/questions/4635403/how-to-set-http-header-x-xss-protection – hh_s Oct 02 '13 at 06:50

5 Answers5

132

This "feature" can be disabled by sending the non-standard HTTP header X-XSS-Protection on the affected page.

X-XSS-Protection: 0
Sophie Alpert
  • 139,698
  • 36
  • 220
  • 238
Kendall Hopkins
  • 43,213
  • 17
  • 66
  • 89
  • 2
    Make sure that the page that is triggering this error is sent with this header, not submitting page. – Kendall Hopkins Aug 15 '12 at 20:31
  • @KendallHopkins....Can you please tell me how can I Use this via Javascript/Java? – SRy Feb 16 '13 at 04:19
  • +1 This answers the question thoroughly unlike the accepted answer however, warns but doesn't give any solution. – JohnnyQ Dec 20 '13 at 15:27
  • 2
    -1 This may "fix" the issue in Chrome, but it does not solve the real problem - your site is still vulnerable to cross-site scripting attacks (more vulnerable in fact) if you do this. The real solution, as @Greg alluded to but did not say explicitly, is to not send HTML/JS back in the response that was submitted in the request. Reading the links he provided should have made that clear. – sfarbota Jun 26 '15 at 19:11
  • @sfarbota There are a lot of cases where this protection is bad. For example it breaks many CMS systems, where it's perfectly acceptable to return back JS that you are editing. But to your point, I wouldn't advise blanket adding this to every page on a site and it's probably only needed in cases where a developer hits this error. – Kendall Hopkins Jul 03 '15 at 07:49
  • Ok, I could see why this could cause problems when developing an application that is actually supposed to take HTML/JS as an input. But I'll go out on a limb and guess that most people facing this issue are not creating a CMS or the next JSFiddle. And even in those cases, I'd bet that most of the time, the issue could be resolved by HTML encoding (or in certain cases URL encoding) the response when it is written back to the screen. – sfarbota Jul 07 '15 at 01:30
68

It's a security measure to prevent XSS (cross-site scripting) attacks.

This happens when some JavaScript code is sent to the server via an HTTP POST request, and the same code comes back via the HTTP response. If Chrome detects this situation, the script is refused to run, and you get the error message Refused to execute a JavaScript script. Source code of script found within request.

Also see this blogpost about Security in Depth: New Security Features.

doekman
  • 18,750
  • 20
  • 65
  • 86
Greg
  • 316,276
  • 54
  • 369
  • 333
  • 5
    It would be nice to see some kind of reference. – kangax Oct 11 '09 at 06:31
  • but is this gona cause any problems? meaning is it ok if we ignore this message? – samach Aug 04 '11 at 12:03
  • @Greg What algorithm is used by browsers to "detect the situation"? It can't be just looking for the string " – Pacerier Jul 13 '12 at 10:09
  • 1
    I would like to see some discussion between this answer the answer from Kendall below regarding the implication of using the X-XSS-Protection: 0 fix. Does it open the site up to XSS attacks? If so is there another way to resolve this error? – dansalmo Oct 06 '12 at 17:31
  • Reference that further explains this, http://blog.chromium.org/2010/01/security-in-depth-new-security-features.html See Reflective XSS Protection section – h--n Nov 16 '12 at 12:57
15

Short answer: refresh the page after making your initial submission of the javascript, or hit the URL that will display the page you're editing.

Long answer: because the text you filled into the form includes javascript, and the browser doesn't necessarily know that you are the source of the javascript, it is safer for the browser to assume that you are not the source of this JS, and not run it.

An example: Suppose I gave you a link your email or facebook with some javascript in it. And imagine that the javascript would message all your friends my cool link. So, the game of getting that link to be invoked becomes simply, find a place to send the javascript such that it will be included in the page.

Chrome and other WebKit browsers try to mitigate this risk by not executing any javascript that is in the response, if it was present in the request. My nefarious attack would be thwarted because your browser would never run that JS.

In your case, you're submitting it into a form field. The Post of the form field will cause a render of the page that will display the Javascript, causing the browser to worry. If your javascript is truly saved, however, hitting that same page without submitting the form will allow it to execute.

Koos Kleven
  • 181
  • 1
  • 4
1

As others have said, this happens when an HTTP response contains a JavaScript and/or HTML string that was also in the request. This is usually caused by entering JS or HTML into a form field, but can also be triggered in other ways such as manually tweaking the URL's parameters.

The problem with this is that someone with bad intentions could put whatever JS they want as the value, link to that URL with the malicious JS value, and cause your users trouble.

In almost every case, this can be fixed by HTML encoding the response, though there are exceptions. For example, this will not be safe for content inside a <script> tag. Other specific cases can be handled differently - for example, injecting input into a URL is better served by URL encoding.

As Kendall Hopkins mentioned, there may be a few cases when you actually want JavaScript from form inputs to be executed, such as creating an application like JSFiddle. In those cases, I'd recommend that you you at least scrub through the input in your backend code before blindly writing it back. After that, you can use the method he mentioned to prevent the XSS blockage (at least in Chrome), but be aware that it is opening you to attackers.

sfarbota
  • 2,619
  • 1
  • 22
  • 30
0

I used this hacky PHP trick just after I commit to database, but before the script is rendered from my _GET request.:

if(!empty($_POST['contains_script'])) { 
    echo "<script>document.location='template.php';</script>";
}

This was the cheapest solution for me.

blo0p3r
  • 6,790
  • 8
  • 49
  • 68
gabrielcrowe
  • 61
  • 4