w3c / webappsec-referrer-policy

WebAppSec Referrer Policy
https://w3c.github.io/webappsec-referrer-policy/
Other
26 stars 27 forks source link

Possible Version 2 #143

Closed craigfrancis closed 2 years ago

craigfrancis commented 4 years ago

Following on from #138, the suggestion from Brian Smith, recognising the current list of keywords can be a little confusing (I need to check a table to see what each one does 1, 2), and the limited ability to customise depending on which domain the request is going to...

How about:

Referrer-Policy:
  full-url 'self' https://shop.example.com;
  origin https://ads.example.com;

When using this syntax, the default would be to send no referrer (safe default), then you can choose who gets the full-url or origin, based on a syntax that's similar to CSP.

I think these are how the current policies would be implemented:

no-referrer
  Referrer-Policy: full-url 'none';

no-referrer-when-downgrade (from HTTPS)
  Referrer-Policy: full-url https://;

no-referrer-when-downgrade (from HTTP)
  Referrer-Policy: full-url *;

same-origin
  Referrer-Policy: full-url 'self';

origin
  Referrer-Policy: full-url 'none'; origin *;

strict-origin
  Referrer-Policy: full-url 'none'; origin https://;

origin-when-cross-origin
  Referrer-Policy: full-url 'self'; origin *;

strict-origin-when-cross-origin
  Referrer-Policy: full-url 'self'; origin https://;

unsafe-url
  Referrer-Policy: full-url *;

I am concerned the unsafe-url version would be very easy to copy/paste without realising that it's unsafe (ref the fun that crossdomain.xml allowed, and how Access-Control-Allow-Origin * fails safe by not working for credentialed requests).

And I'll note that a referrerpolicy on <a>/<area>/<img>/<iframe>/<script>/<link> currently allows you to override the header for specific requests (and the very minor security concern, if someone malicious was able to add a link with this attribute, which a HTML sanitiser might allow).

Malvoz commented 4 years ago

Commenting only on this part:

referrerpolicy on <a>/<area>/<img>/<iframe>/<script>/<link> currently allows you to override the header for specific requests

There's a WHATWG HTML issue about potentially enabling capping the referrer information in https://github.com/whatwg/html/issues/5041.

domfarolino commented 2 years ago

Commenting only on this part:

referrerpolicy on <a>/<area>/<img>/<iframe>/<script>/<link> currently allows you to override the header for specific requests

There's a WHATWG HTML issue about potentially enabling capping the referrer information in whatwg/html#5041.

Yes, let's try and separate the two things (a) this proposal, which allows for more granular referrer policy setting per-origin, and (b) the idea that per-request referrerpolicy= attributes can loosen the referrer policy specified in a header or meta tag.

This proposal (a) is interesting, but I think it is unlikely to be pursued by browsers at this point. It would require some complicated changes to this and other specs, and I see most of the impact from referrer policy as having already been achieved. I think a good next step for this would be to post something on https://discourse.wicg.io/ to see if there is a larger community appetite for this, or even interest from other browser vendors.

Thanks a lot for the proposal, feel free to write back here if we come across larger community support.