default referrer-policy for secure-headers middleware

[Jxck]

What is the feature you are proposing?

Default Referrer-Policy for secure-headers middleware

Currently the default referrer-policy is no-referrer.

https://github.com/honojs/hono/blob/main/src/middleware/secure-headers/index.ts#L73

When referrer-policy sets no-referrer, it also hides not only referer header but also origin header.

https://fetch.spec.whatwg.org/#origin-header

• "no-referrer"
  • Set serializedOrigin to null.

Origin header is very important for mitigating CSRF attacks. So making it null can make the application less secure, since the application server can't make sure it really comes from the same origin.

What makes it secure is not hiding every referrer, but avoiding leaking much information for cross origin servers. There's no reason to avoid sending the referrer value to the same origin server.

What should be the default

There are many choices on Referrer-Policy but I prefer using strict-origin-when-cross-origin.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy#strict-origin-when-cross-origin_2

It minimizes information leaks and keeps sending origin for keep origin header based csrf guards works.

same-origin seems an alternative for securerer headers, but it hides sending origin to cross origin. In this case, it can cause some problems if your application interacts with cross origin services.

That's the reason why strict-orign-when-cross-orign is the default policy for modern browsers now.

but it's one of the practices to explicitly set strcit-origin-when-cross-orign from middleware to make sure it is enabled.

[yusukebe]

Hi @Jxck

I appreciate your suggestion. It makes sense to me. I also the strict-origin-when-cross-origin is good.

@watany-dev What do you think about this?

[watany-dev]

@Jxck @yusukebe Personally, I think it makes sense. The decision-making in Helmet, which inspired this secure-headers middleware, seems to have been focused on prioritizing security like this.

https://github.com/helmetjs/helmet/issues/333

Based on this, I believe the discussion points are as follows:

1. Compatibility with Express. This might simply be addressed by including the useHelmetDefaults: true option.
2. Changing the default setting in secure-headers might not appear problematic in most cases, but there is a concern that it could impose a breaking change on current users by inadvertently reducing their security. This particularly holds if the changes are implemented in a minor version update, potentially altering users' established security configurations without clear notification.