Properly handle HTTP header 'Referrer-Policy'

[ghost]

Description

Properly set HTTP Security Header Referrer-Policy instead of relying on browser or environment defaults.

Use case / motivation

I'm not sure if this is a feature or a bug, but first wanted to start a discussion at all.

1. Airflow in some places has a hard requirement that the referrer header is required for navigation/functionality, e.g. here.
   There are numerous places where this header is not needed.

2. I'm deferring to an external source which gives a good overview and makes good arguments why to set it explicitly:

   Why "explicitly"?
   If no referrer policy is set, the browser's default policy will be used - in fact, websites often defer to the browser's default. But this is not ideal, because:

   • Browser default policies are either no-referrer-when-downgrade, strict-origin-when-cross-origin, or stricter - depending on the browser and mode (private/incognito). So your website won't behave predictably across browsers.
   • Browsers are adopting stricter defaults such as strict-origin-when-cross-origin and mechanisms such as referrer trimming for cross-origin requests. Explicitly opting into a privacy-enhancing policy before browser defaults change gives you control and helps you run tests as you see fit.

   Therefore, we have an implicit coupling to browser's default behaviour.

3. There are (suggested) best-practices like injecting "secure" headers yourself in case the application does not provide explicit values. This example uses service mesh functionality to set Referrer-Policy: no-referrer if the service/pod app does not set something itself.

---

→ There are three obvious ways to tackle this:

1. Document the "minimum requirement", e.g. explicitly stipulate the lack of support for policies like Referrer-Policy: no-referrer.
2. Explicitly set a sane (configurable?) global value, e.g. strict-origin-when-cross-origin.
3. Explicitly set specific values, depending on which page the user is on (and might go to).

Are you willing to submit a PR?

That depends on the preferred solution 😬.
I'm quite new in this area but might be able to tackle solutions 1/2 with some guidance/help.
At the same time I feel like 3 is the "proper" solution and for that I lack a lot of in-depth Airflow knowledge

Related Issues

[boring-cyborg]

Thanks for opening your first issue here! Be sure to follow the issue template!

[uranusjr]

A lot of the current usages of request.referrer can (should) absolutely go away IMO, including the one you mentioned (in refresh)—the page to redirect back to should be passed in as a request.values field instead. I am not sure whether all of them can go, but let’s try first replacing them and find out.

[utkarsharma2]

@uranusjr , I would like to contribute for this issue, can you assign this to me?

[uranusjr]

Go ahead!