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.

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

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.