|WikiProject Computer Security / Computing||(Rated Start-class, High-importance)|
|WikiProject Internet||(Rated Start-class, Mid-importance)|
Cookies have been 'per domain' ever since Netscape introduced them. Is this also an example of 'same origin policy'? --AndersFeder 16:53, 23 February 2007 (UTC)
I'm seeing cookies set by http://192.168.1.128:9000 being sent to http://192.168.1.128:8000 in both FF4.0 and Chrome. Is this normal? Do cookies have an exception to Same Origin Policy? Should this be made clear on the main page? Chris Dew 9:53, 14 June 2011 (GMT)
@chrisdew.Chris DewThis explain that one origin is permitted to send information to another origin, but one origin is not permitted to receive information from another origin.Which can explain you situation.http://www.w3.org/Security/wiki/Same_Origin_Policy.--cattail (talk) 13:00, 11 October 2012 (UTC)
The article previously said the Internet Explorer doesn't pay attention to port. However, in my tests, Internet Explorer does pay attention to port. It may be that setting document.domain gets around this; however, setting document.domain gets around the same-domain restrictions too, so it isn't really fair to say that IE cares about domains but not ports. Rulesdoc (talk) 23:17, 2 April 2008 (UTC)
Overcoming access restriction
The same-origin policy does not apply to HTML files run from the local filesystem. This makes it possible for a locally-run HTML file to, for instance, perform any given HTTP request.
From my experiment (firefox 1.0.7, IE5), html files run in local filesystem can perform http request, but can't access data returning from that request. Morever, html files run in non-local can still perform any http request, but just can't access data. --Ans (talk) —Preceding comment was added at 09:28, 9 May 2008 (UTC)
The same origin policy protects many other site-specific resources besides cookies, such as HTTP authenticated sessions, saved passwords, and the localStorage API. It protects the confidentiality of the file system from the web. When combined with HTTPS it can protect against network attackers. It is used as a building block for cross-site request forgery defenses and click fraud defenses. It protects the integrity of a page I'm viewing from other tabs I may have open that may wish to corrupt it -- ensuring, for example, that passwords I enter into login forms are sent to the correct place. Rulesdoc (talk) 06:02, 3 November 2008 (UTC)
The following article provides a good explanation of the threat model: http://blogs.msdn.com/b/ieinternals/archive/2009/08/28/explaining-same-origin-policy-part-1-deny-read.aspx — Preceding unsigned comment added by 22.214.171.124 (talk) 23:43, 29 August 2011 (UTC)
I took the liberty of redoing much of the article, including removing unrelated or incorrect data (such as the suggestion that security zones are a replacement for same-origin checks, mentions that browsers can be modified to bypass the policy, or a needlessly verbose discussion of XSRF), improving some of the remaining text (such as an inaccurate explanation of document.domain behavior, or rewording the text that implied the security context is derived from where the script, rather than the page running it, originated). Let me know if I butchered it too much, but seems to be more readable this way. The links should substantiate most of the claims made, so I did not bother with too many refs for statements that are generally easy to verify.
I also removed a bunch of redundant links, and, full disclosure, plugged a part of a work I authored, Browser Security Handbook; the only reason for doing it is that it's almost certainly the most comprehensive, detailed, and up-to-date discussion of same origin policies out there. Hope that's OK, if not, feel free to revert to the crappy old set, or better yet, find a good replacement ;-) --lcamtuf (talk) 19:08, 10 January 2009 (UTC)
"Same" vs. "Single"
- Very good point. In fact, at present, it is "single site policy", this policy should be extended to "same origin policy". So then we need a specification of "same origin", i.e. a web application can access to a set of sites rather than only one individual site. Furthermore, it is easy to extend this. As long as the browsers can take it. For example, just add one more attribute to the link element in the html head to specify same origin. Jackzhp (talk)
For security reason, the same origin policy is good, but at present, it is implemented as the single site policy. I think that we can extend the defato "single site policy" to the authentic "same origin policy", i.e. to define origin explicitly. More specific, we can define an origin be a set of url (which specifies the protocal, host, and port). Jackzhp (talk) 00:06, 26 June 2011 (UTC)
"In a nutshell" redundant
To my thinking, it's redundant to say "In a nutshell" -- the statement occurs in the first paragraph of the article, which is by definition a summary or "in a nutshell" paragraph.
EasyXDM URL in the article
This URL is hard-coded into the article which is inappropriate. Whoever did this, add an article or make a reference if easyXDM merits the attention.
External links belong in that section or in references.
Or am I mistaken? G. Robert Shiplett 00:44, 16 July 2011 (UTC)
The article says:
"Origin determination rules" Missing Info
Thanks. — Preceding unsigned comment added by 126.96.36.199 (talk) 09:40, 28 December 2012 (UTC)
|This section or list is incomplete. Please help to improve it, or discuss the issue on the talk page.|
This article explains how the Same origin policy works as well as how to get around it, but doesn't explain what problems it was created to prevent. Perhaps a section on that should be added? --188.8.131.52 (talk) 09:51, 7 March 2013 (UTC)