same-origin-policy

I've been investigating frame breaking code recently and have come across some really bizarre behavior related to the same origins policy that I am having trouble understanding. Suppose I've got a page Breaker.html on domain A, and a page Container.html on domain B. The example frame breaker code would go into Breaker.html, like below: if (top !== self) top.location.href = self.location.href; This will successfully break Breaker.html out of Container.html, but I don't understand why it should. From my reading of the same origins policy, top.location shouldn't be accessible at all , since

I've been reading up on CORS and how it works, but I'm finding a lot of things confusing. For example, there are lots of details about things like User Joe is using browser BrowserX to get data from site.com , which in turn sends a request to spot.com . To allow this, spot has special headers... yada yada yada Without much background, I don't understand why websites wouldn't let requests from some places. I mean, they exist to serve responses to requests, don't they? Why would certain people's of requests not be allowed? It would really appreciate a nice explanation (or a link to one) of the

I'm working on a web-based tool which streamlines the work we do at my office. The tools provided to us by our partner have a generic login that our entire floor uses, but it times out every 30 minutes, which is annoying to have to log-into again all day. What I had done in the past, was create a hidden iframe inside my tool which logs into it by submitting a hidden form on page load, and continuing to submit the form every 30 minutes to prevent a timeout. They can then submit searches to the partner tool directly from my tool (via another, visible form). I'd like to use jQuery $.post() to

The command --disable-web-security to allow for cross domain requests on Chrome is no longer working, I presume due to the latest update. Is there a workaround for this, besides downloading an older version of chrome and disabling updates? Might as well ask in the same question, the javascript snippet suggested to turn off web security in Firefox never works for me: try { netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserRead"); } catch (e) { alert("UniversalBrowserRead failed"); } The page always alerts UniversalBrowserRead failed . Kill all instances and try again. Had the

(If needed, please see my last question for some more background info.) I'm developing an app that uses a decoupled front- and backend: The backend is a Rails app (served on localhost:3000 ) that primarily provides a REST API. The frontend is an AngularJS app, which I'm building with Gulp and serving locally (using BrowserSync ) on localhost:3001 . To get the two ends to talk to each other, while honoring the same-origin policy , I configured nginx to act as a proxy between the two, available on localhost:3002 . Here's my nginx.conf: worker_processes 1; events { worker_connections 1024; } http

Overview and original question window.name is an interesting beast. MDN's description hints at the original intent: The name of the window is used primarily for setting targets for hyperlinks and forms. Windows do not need to have names. So, this means we can open the console in this window, and write: var win = window.open('http://google.com', 'el goog'); ...and then let it through the popup blocker, that should open google.com in a window named "el goog." I can't access the name property of win because of the same-origin policy, but if I open a console in the new window and type name , I'll

I load a local html file (from assets folder) to the app WebView. In the HTML I run a jQuery.getJSON(url). the url is a remote server. This action fails, and I'm guessing because of a different origin issue (cross domain). I run the same file on chrome and there it specifically says so. Is there a way to allow the WebView in Android to load data from remote server on a local loaded HTML file? Today morning I found solution that seems to be working. The Java part Initialize your WebView: WebView _webView = (WebView) this.findViewById(R.id.id_of_your_webview_in_layout); get WebView settings:

First of all, I assume a backend that control inputs to prevent XSS vulnerabilities. In this answer @Les Hazlewood explain how to protect the JWT in the client side. Assuming 100% TLS for all communication - both during and at all times after login - authenticating with username/password via basic authentication and receiving a JWT in exchange is a valid use case. This is almost exactly how one of OAuth 2's flows ('password grant') works. [...] You just set the Authorization header: Authorization: Bearer <JWT value here> But, that being said, if your REST client is 'untrusted' (e.g. JavaScript