77

I'm getting this error in Firefox's Console: SecurityError: The operation is insecure and the guilty is HTML5 feature: window.history.pushState() when I try to load something with AJAX. It is supposed to load some data but Javascript stops executing on error.

I'm wondering why this may be happening. Is this some server misconfiguration? Any help would be appreciated.

UPDATE: Yes, it was a server error with domain name not matching: http://en.wikipedia.org/wiki/Same-origin_policy

Atadj
  • 7,050
  • 19
  • 69
  • 94
  • 9
    Are you accessing on a `file:///` URL? – robertc Nov 12 '12 at 18:01
  • @robertc what do you mean? It's `http://` all the time. I suspect it might be because of usage of sub-domain but `pushState` tries to push just `/`, so it shouldn't have any impact. – Atadj Nov 12 '12 at 18:04

11 Answers11

50

Make sure you are following the Same Origin Policy. This means same domain, same subdomain, same protocol (http vs https) and same port.

How does pushState protect against potential content forgeries?

EDIT: As @robertc aptly pointed out in his comment, some browsers actually implement slightly different security policies when the origin is file:///. Not to mention you can encounter problems when testing locally with file:/// when the page expects it is running from a different origin (and so your pushState assumes production origin scenarios, not localhost scenarios)

Community
  • 1
  • 1
Matt
  • 41,216
  • 30
  • 109
  • 147
  • 10
    how to use `pushState` with `file:///` then? – Sashko Lykhenko Oct 19 '18 at 01:52
  • @SashkoLykhenko You don't. In general, browsers apply tighter security restrictions to `file://` URI. Browsers treat `file://` URI as though they come from unique origins even if the files they reference are on the same system. So anything that requires a cross-origin check fails when used in conjunction with `file://` URI. – Ouroborus May 29 '23 at 19:21
14

We experienced the SecurityError: The operation is insecure when a user disabled their cookies prior to visiting our site, any subsequent XHR requests trying to use the session would obviously fail and cause this error.

oliverguenther
  • 1,167
  • 1
  • 17
  • 31
  • 1
    When a user disables their cookies, you can wrap XHR request code in a try/catch block and use the `catch` to prompt the user to enable cookies. Wrap `window.localStorage`, `window.history.pushState()` or any XHR requests. – jeremysmith Nov 11 '18 at 07:05
5

In my case I was missing 'www.' from the url I was pushing. It must be exact match, if you're working on www.test.com, you must push to www.test.com and not test.com

Adam
  • 6,041
  • 36
  • 120
  • 208
5

You should try not open the file with a folder-explorer method (i.e. file://), but open that file from http:// (i.e. http://yoursite.com/ from http://localhost/)

T.Todua
  • 53,146
  • 19
  • 236
  • 237
4

I had this problem on ReactJS history push, turned out i was trying to open //link (with double slashes)

Ayoub Laazazi
  • 540
  • 7
  • 15
2

I had the same problem when called another javascript file from a file without putting javascript "physical" address. I solved it by calling it same way from the html, example: "JS / archivo.js" instead of "archivo.js"

hectorpyco
  • 21
  • 1
2

When creating a PWA, a service worker used on an non https server also generates this error.

Dror
  • 2,370
  • 1
  • 18
  • 13
1

replace serviceWorker.unregister() to serviceWorker.register() in index.js file

LOVENEET SINGH
  • 193
  • 2
  • 9
1

I solved it by switching tohttp protocol from the file protocol.

  • you can use "live-server" extension in VS code,
  • or, on node, use live-server [dirPath]
Rahul Dahal
  • 152
  • 1
  • 12
1

I had the same problem and it was caused by setting <base href=> to a naked domain while my server always served the www domain. Adding the www to the url in base href solved the issue.

Mathieu Dhondt
  • 8,405
  • 5
  • 37
  • 58
1

You should disable blocking of cross sire cookies in security settings of browser.

Alex78191
  • 2,383
  • 2
  • 17
  • 24