Copyright © 2011 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
The From-Origin Header specification defines the
From-Origin
response header — a way for
resources to declare they are unavailable within an embedding context.
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 21 July 2011 First Public Working Draft of The From-Origin Header. Please send comments to public-webapps@w3.org (archived) with [from-origin] at the start of the subject line.
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 Draft 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.
From-Origin
Response HeaderAll 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
problems:
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
addressed by From-Origin
?
From-Origin
Response HeaderThe 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
being fetched.
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 instead.
Otherwise, proceed as normal.
Thanks to Adam Barth, David Singer, Glenn Maynard John Daggett, Jonathan Rees, Håkon Wium Lie, Henri Sivonen and Ms2ger for their useful comments.