Talk:Same-origin policy

This is the talk page for discussing improvements to the Same-origin policy article.
This is not a forum for general discussion of the article's subject.

Put new text under old text. Click here to start a new topic.
New to Wikipedia? Welcome! Learn to edit; get help.

Article policies

Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL

Computer Security: Computing High‑importance

This article is within the scope of WikiProject Computer Security, a collaborative effort to improve the coverage of computer security on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.Computer SecurityWikipedia:WikiProject Computer SecurityTemplate:WikiProject Computer SecurityComputer Security articles

High

This article has been rated as High-importance on the project's importance scale.

This article is supported by WikiProject Computing (assessed as High-importance).

Things you can help WikiProject Computer Security with:

Article alerts will be generated shortly by AAlertBot. Please allow some days for processing. More information...

Review importance and quality of existing articles
Identify categories related to Computer Security
Tag related articles
Identify articles for creation (see also: Article requests)
Identify articles for improvement
Create the Project Navigation Box including lists of adopted articles, requested articles, reviewed articles, etc.
Find editors who have shown interest in this subject and ask them to take a look here.

Internet Mid‑importance

	Internet portal This article is within the scope of WikiProject Internet, a collaborative effort to improve the coverage of the Internet on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.InternetWikipedia:WikiProject InternetTemplate:WikiProject InternetInternet articles
Mid	This article has been rated as Mid-importance on the project's importance scale.

Cookies

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)[reply]

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 2014 (UTC)[reply]

Port

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)[reply]

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)[reply]

Threat

As the article stands it is unclear who is at risk. Suppose user B runs a browser and visits web site C which contains JavaScript that attempts to access site D. Who looses and what is lost if the access is allowed? What nefarious end can site C author accomplish in this scenario that he cannot accomplish by directly accessing site D.

Tentative answer: The malicious JavaScript can send messages to site D that appear to D as if they were due to an action of B. This is due to cookies stored at the browser due to previous actions by site D, that the browser includes with the bogus message from the JavaScript program. The JavaScript program thus runs with and abuses B's authority! This causes site D to interpret the message as one originating from B's action. This is bad if D is a bank and B is a bank customer. The message may be crafted to cause money from B's account to move indirectly to C's account.

Are there threats besides the abuse of cookies? NormHardy (talk) 22:10, 1 November 2008 (UTC)[reply]

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)[reply]

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 50.83.15.223 (talk) 23:43, 29 August 2011 (UTC)[reply]

Major changes

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)[reply]

"Same" vs. "Single"

I think this page should disambiguate from "Single Origin Policy" as well. Both terms are in use. I'd add that but I don't know how to do it. patniemeyer (talk) 14:46, 18 March 2009 (UTC)[reply]

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)[reply]

"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.

Karl gregory jones (talk) 00:18, 18 March 2010 (UTC)[reply]

EasyXDM URL in the article

http://easyxdm.net/wp/

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)

Predating JavaScript -> Include scripts across domains

The article says:

... many legacy cross-domain operations predating JavaScript are not subjected to same-origin checks; one such example is the ability to include scripts across domains ...

I don't understand how including scripts across domains can be considered a cross-domain operation that predates JavaScript. Am I missing something? Gilly3 (talk) 00:39, 17 October 2012 (UTC)[reply]

"Origin determination rules" Missing Info

The table and information in this section doesn't clarify any affect on files(locally). For example, when using "file:///C:/Location/a_file.htm" would the javascript protocols prohibit anything to happen to any files around it? say "file:///C:/Location/another_file.htm"
Thanks. — Preceding unsigned comment added by 98.237.13.239 (talk) 09:40, 28 December 2012 (UTC)[reply]

No. The same origin policy treats files in the same directory as same origin meaning that JavaScript calls could read files in the same directory. This was alerted in [1]https://www.mozilla.org/en-US/security/advisories/mfsa2019-21/#CVE-2019-11730 as a vulnerability that can arise when a user is tricked into downloading an HTML attachment. If the attachment is opened in a browser, the JavaScript in the attachment would be able to read other files saved in the same directory. See also: [2]https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS/Errors/CORSRequestNotHttp Tim (talk) 19:07, 30 August 2024 (UTC)[reply]

Reasoning

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? --202.213.201.225 (talk) 09:51, 7 March 2013 (UTC)[reply]

I agree; the article goes into exceptions, but what it really needs is an example of what this policy actually applies to. -- Beland (talk) 17:12, 9 June 2014 (UTC)[reply]

I added a short piece to history to explain the generic exploit. Is that sufficient? 2015-11-18 — Preceding unsigned comment added by Rocketpipe (talk • contribs) 20:59, 18 November 2015 (UTC)[reply]

Security Concerns Section

I added a new section to make it clear what all this is about. In the first section (introduction), second paragraph, there are two sentences mentioning the same thing (HTTP cookies, user sessions, sensitive information, state-changing actions), but a bit confusing and very short. Users reading this probably won't understand it from this short part, therefore I added the new section. Feel free to merge the two. But I would rather see to expand the new section with some flow chart drawings and more examples. The same-origin policy is something that affects many developers and they just think this is nonsense or simply allow CORS headers for everyone, so it is important that the risks are fully understood, especially as developers might come to Wikipedia first. --165.222.185.144 (talk) 18:27, 23 March 2016 (UTC)[reply]

Can I succeed

Will you all help me until I get the hang of this Stevo47 (talk) 06:08, 14 November 2017 (UTC)[reply]

"Scripts" vs other assets vs XHR responses

The words "it is very important to remember" triggered a wikipedian in me as original research. Besides, the point of SOP is missed. I believe SOP prevents the UI origin's javascript from reading embedded assets (except for some metadata such as picture sizes) and XHR responses across origins. Plus I think SOP does not prevent from sending data across origins. Plus I think SOP may have a flaw in allowing to read and modify global variables used in embedded cross-origin scripts. --ilgiz (talk) 14:39, 29 May 2019 (UTC)[reply]

Explaining abbreviations before use

I introduced revision 1241654835. This user reverted the change. The change was necessary both to explain an abbreviation before its first use, and to make the first usage of the abbreviation make grammatical sense; the reverted version reintroduces a grammatical error. I am writing this to avoid an edit war. Henrebotha (talk) 15:39, 19 September 2024 (UTC)[reply]

@Henrebotha , thank you for your help🩵 2601:5CC:8300:5280:C3AE:151B:35BC:82EC (talk) 02:37, 20 September 2024 (UTC)[reply]

AXLER ARNALDO PORTALES

Si Cotoca 69167831si 181.41.151.109 (talk) 11:56, 18 October 2024 (UTC)[reply]

Wiki Education assignment: Engineering in the 21st Century - Section 003

This article is currently the subject of a Wiki Education Foundation-supported course assignment, between 19 August 2024 and 3 December 2024. Further details are available on the course page. Student editor(s): Secure Cyberspace (article contribs).

— Assignment last updated by GroupScientificDiscovery (talk) 02:50, 28 October 2024 (UTC)[reply]