The same-origin policy restricts how a document or script loaded from one origin can interact with a resource from another origin.
Definition of an origin
Two pages have the same origin if the protocol, port (if one is specified), and host are the same for both pages. The following table gives examples of origin comparisons to the URL
See also origin definition for
Cookies use a definition of origins, which is different from the above.
A page may change its own origin with some limitations. A script can set the value of
document.domain to a suffix of the current domain. If it does so, the shorter domain is used for subsequent origin checks. For example, assume a script in the document at
http://store.company.com/dir/other.html executes the following statement:
document.domain = "company.com";
After that statement executes, the page would pass the origin check with
http://company.com/dir/page.html. However, by the same reasoning,
company.com could not set
Port number is kept by the browser separately. Any call to the setter, including
document.domain = document.domain causes the port number to be overwritten with
null. Therefore one can not make
company.com:8080 talk to
company.com by only setting
document.domain = "company.com" in the first. It has to be set in both so that port numbers are both
Cross-origin network access
The same-origin policy controls interactions between two different origins, such as when you use
XMLHttpRequest. These interactions are typically placed in three categories:
- Cross-origin writes are typically allowed. Examples are links, redirects and form sumissions. Certain rarely used HTTP requests require preflight.
- Cross-origin embedding is typically allowed. Examples are listed below.
- Cross-origin reads are typically not allowed, but read access it often leaked by embedding. For example you can read the width and height of an embedded image, the actions of an embedded script, or the availability of an embedded resource.
Here are some examples of resources which may be embedded cross-origin:
<script src="..."></script>. Error messages for syntax errors are only available for same-origin scripts.
- CSS with
<link rel="stylesheet" href="...">. Due to the relaxed syntax rules of CSS, cross-origin CSS requires a correct
Content-Typeheader. Restrictions vary by browser: IE, Firefox, Chrome, Safari (scroll down to CVE-2010-0051) and Opera.
- Images with
<img>. Supported image formats include PNG, JPEG, GIF, BMP, SVG, ...
- Media files with
- Plug-ins with
- Fonts with
@font-face. Some browsers allow cross-origin fonts, others require same-origin fonts.
- Anything with
<iframe>. A site can use the
X-Frame-Optionsheader to prevent this form of cross-origin interaction.
How to allow cross-origin access
Use CORS to allow cross-origin access.
How to block cross-origin access
- To prevent cross-origin writes, check for an unguessable token in the request, known as a Cross-Site Request Forgery (CSRF) token, and prevent cross-origin reads of pages that know this token.
- To prevent cross-origin reads of a resource, ensure that it is not embeddable.
- To prevent cross-origin embedding, ensure that your resource can not be interpreted as one of the embeddable formats listed above. The browser does not respect the
Content-Typein most cases. For example if you point a
Cross-origin script access
window.opener allow documents to directly reference each other. When the two documents do not have the same origin, these references provide limited access to the Window and Location objects. Some browsers allow access to more properties than the spec allows. You can use
window.postMessage instead to communicate between documents.
Original Document Information
- Author(s): Jesse Ruderman