The From-Origin Header specification defines the
From-Origin response header — a way for
resources to declare they are unavailable within an embedding context.
Beware. This specification is no longer in active maintenance and the Web Applications Working Group does not intend to maintain it further.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This is the 29 May 2012 W3C Working Group Note of The From-Origin Header. Please send comments to firstname.lastname@example.org (archived) with [from-origin] at the start of the subject line.
This specification is no longer actively maintained due to lack of implementor interest. If you plan on implementing this specification please let the aforementioned mailing list know so abandoning it can be reconsidered. Thanks!
This document is produced by the Web Applications (WebApps) Working Group. The WebApps Working Group is part of the Rich Web Clients Activity in the W3C Interaction Domain.
The contents of this document do not necessarily reflect the consensus of the Working Group.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
Publication as a Working Group Note does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
All diagrams, examples, and notes in this specification are non-normative, as are all sections explicitly marked non-normative. Everything else in this specification is normative.
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this document are to be interpreted as described in RFC2119. For readability, these words do not appear in all uppercase letters in this specification. [RFC2119]
The terminology used in this specification is from HTML and The Web Origin Concept [HTML] [ORIGIN]
The Web platform has no limitations on embedding resources from different
origins currently. E.g. an
HTML document on
http://example.org can embed an image from
http://corp.invalid without issue. This has led to a number of
This specification attempts to tackle these problems to some extent.
Privacy leakage can however still be a problem if the resource in question has different latency characteristics depending on the I'm-signed-in-cookie being present.
Should we try to phase out
X-Frame-Options and replace it with
this header or extend
X-Frame-Options to cover the cases
From-Origin header can
be used to restrict embedding of a resource to only certain
origins. When used it must
match the following ABNF:
From-Origin = "From-Origin" ":" #(serialized-origin | "same")
The ABNF used is defined by HTTP. [HTTP]
When a resource is fetched these steps must be run in addition to the steps that are being run for fetching the resource. They must be run as if they were part of the fetching algorithm's main step and if a network error is to be returned rather than a resource the fetching algorithm must be terminated meaning e.g. cookies will not be updated. If this algorithm ends for other reasons fetching must proceed as normal.
If the resource being
fetched does not carry a
From-Origin header or it cannot be
parsed per the above BNF terminate these steps.
If the resource is being fetched as the result of navigating a non-child browsing context terminate these steps.
We do not want to restrict non-embedding scenarios.
Let source origin be the origin of the API that caused the resource to be fetched or the origin of the source browsing context if the fetching was the result of navigating.
Let target origin be the origin of the resource being fetched.
If source origin and target origin are same origin terminate these steps.
We do not want to restrict same-origin scenarios.
Let allowed origins be the values of the
From-Origin header(s) of the resource
If none of the values of allowed origins are equal to the source origin, instead of returning the resource being fetched, return a network error.
Otherwise, proceed as normal.
Thanks to Adam Barth, David Singer, Giuseppe Pascale, Glenn Adams, Glenn Maynard, John Daggett, Jonathan Rees, Håkon Wium Lie, Henri Sivonen, and Ms2ger for their useful comments.