The From-Origin Header

Abstract

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

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.

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:

• Bandwidth "theft" — the practice of embedding resources (e.g. images or fonts) from another server causing the owner of that server to get a higher hosting bill.
• Clickjacking — embedding a resource from another origin and attempting to let the visitor click on a concealed link thereof, causing harm to the visitor.
• Privacy leakage — sometimes resource availability depends on whether a visitor is signed in to a particular website. E.g. only with a I'm-signed-in-cookie will an image be returned, otherwise an HTML document. An HTML document embedding a resource (requested with the user's credentials) can figure out the existence of that resource and thus whether the visitor is signed in and therefore has an account with a particular service.
• License checking — certain font licenses require that the font be prevented from being embedded on other origins.

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

8. Otherwise, proceed as normal.

References

Normative references

Acknowledgements

Thanks to Adam Barth, David Singer, Glenn Maynard John Daggett, Jonathan Rees, Håkon Wium Lie, Henri Sivonen and Ms2ger for their useful comments.