W3C home > Mailing lists > Public > public-webappsec@w3.org > November 2014

Referrer Policy: Same-origin URIs

From: Devdatta Akhawe <dev.akhawe@gmail.com>
Date: Sat, 8 Nov 2014 14:14:55 -0800
Message-ID: <CAPfop_3Ua3nLpii854N=bK7z+9jdHYf9C3LRCG97kQAuoAF7+g@mail.gmail.com>
To: "public-webappsec@w3.org" <public-webappsec@w3.org>, Mike West <mkwst@google.com>, eisinger@google.com
Hi

Can we have a referer policy directive that lets the web application
specify the a same-origin URI to use as a referer?

http://www.w3.org/TR/referrer-policy/ defines origin-only and
origin-when-cross-origin as two new policies to limit the referer sent
to a useful yet not secret value.*

Now, imagine there is a URL,
example.com/capabilityurls/SuperlongSecretValue that I want to keep a
secret. Here are my options on setting the referer policy for the
page.

1. I can set it to origin-when-cross-origin. This works great for
ensuring that other domains don't get access to the referrer. But,
this does mean that the refer can leak on pages that are same origin.
That makes me sad.

2. I can set the referrer policy to origin only. Unfortunately,
"origin" only is not usually easy to deploy since for internal
tracking (lets say there is a help center article page), it would be
nice to know that the user clicks on it from a /capabilityurls
location. None has a similar problem.


What I really want is the ability to say "send the referer value of
/capabilityurls" (or whatever the handler for the set of URLs is). I
can already modify the referer value by just doing the
history.pushState but as soon as I do that, the user can't copy paste
the capability URL, which is often a useful feature.

Can we get a referer policy directive that allows setting the referer
to a same-origin URI? I don't see any security concerns with this. JS
on the page can already kinda modify the referer to be sent with
history.pushState and CSP is at a level of trust higher than the JS on
the page.


thanks
Dev

* In contrast, "unsafe-url", "none", and "none-when-downgrade" fall in
the "all or nothing" bucket and not in the "useful yet restricted"
category.
Received on Saturday, 8 November 2014 22:15:45 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:07 UTC