The From-Origin Header

W3C Working Group Note 29 May 2012

This Version:
Latest Version:
Latest Editor Draft:
Previous Versions:
Anne van Kesteren (Opera Software ASA) <annevk@annevk.nl>


The From-Origin Header specification defines the From-Origin response header — a way for resources to declare they are unavailable within an embedding context.

Status of this Document

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 public-webapps@w3.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.

Table of Contents

  1. 1 Conformance
  2. 2 Terminology
  3. 3 Introduction
  4. 4 From-Origin Response Header
  5. References
    1. Normative references
  6. Acknowledgements

1 Conformance

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]

2 Terminology

The terminology used in this specification is from HTML and The Web Origin Concept [HTML] [ORIGIN]

3 Introduction

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?

4 From-Origin Response Header

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

  1. If the resource being fetched does not carry a From-Origin header or it cannot be parsed per the above BNF terminate these steps.

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

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

  4. Let target origin be the origin of the resource being fetched.

  5. If source origin and target origin are same origin terminate these steps.

    We do not want to restrict same-origin scenarios.

  6. Let allowed origins be the values of the From-Origin header(s) of the resource being fetched.

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

  8. Otherwise, proceed as normal.


Normative references

HTML5, I. Hickson. W3C.
Hypertext Transfer Protocol -- HTTP/1.1, R. Fielding, J. Gettys, J. Mogul et al.. IETF.
The Web Origin Concept, A. Barth. IETF.
Key words for use in RFCs to Indicate Requirement Levels, S. Bradner. IETF.


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.