Is using two cookies one Lax and one Strict a way to improve usability without compromising security?

Question

My understanding is that

• Strict is the best as, admitting you have a recent browser, it completely replaces the need for CSRF Token.
• Strict is however a big hit on usability as things like SSO or just having a link in email to go to a logged page will load the page without the cookie.

Would it be viable approach if :

1. The user start a session (logs to a website example.com for example)
2. example.com set a Lax one with just "has_a_strict_cookie=true"
3. example.com also set a Strict one with your usual session id etc. in it
4. The user-agent request a resource /should/be/logged/sensitive
5. example.com backend checks:
   • if the Strict cookie is sent, we are in normal "same origin" navigation, the resource sensitive is transmistted
   • if only the Lax cookie is present, it means the user has a session BUT it comes from a "cross origin" context, in which case example.com could redirect to example.com/intermediate/page with a link (and auto javascript click on the link?) to the sensitive resource, so that the Strict cookie is then sent ?
   • if neither are present it means the user has no session at all and we simple redirect to a login page

In term of security:

• only the Strict cookie allow access to sensitive information (session id) so it's not possible to become lazy and to start to only rely on the Lax cookie
• The redirection on the intermediate page does not disclose more information than a redirect to a login page would have

In term of usability:

• You can have external link to sensitive resource / SSO scheme
• The only compromise is to have during a second an intermediate page

Am I missing something ? If not, why is not advertised more ? Most resources on the web as of 2023 seems to be "Either use Strict if you need absolute security and can live with its limitation or use Lax but you're not fully protected against CSRF attack on GET resource that modify state"

Answer 1

If the redirection from example.com/intermediate/page to example.com/should/be/logged/sensitive happens automatically, the strict cookie is sent (unless it is an HTTP redirect, see here). If example.com contained such an automatic redirect, it would defeat the purpose of the strict cookie, because the user can be tricked into making these two requests (thus accessing the sensitive document without wanting to).

Compromising security in this way can only be avoided if user interacts with the intermediate page and thereby expresses their consent to what follows (for example, accessing the sensitive document) by pressing a button or so. This can be achieved in two ways:

1. The session cookie is strict, and there is an additional lax cookie. If only the lax cookie is present:

   1. For requests that must not be made inadvertently, users must press a button that triggers a redirect.
   2. For other requests, the redirect can be triggered automatically. (These "other requests" are the majority, for example, loading the stackoverflow.com page of a logged-in user.)

   In either case, the request resulting from the redirect then contains the strict session cookie.

2. The session cookie is lax instead of strict so that the request already contains it.

   1. Requests that must not be made inadvertently additionally demand a CSRF protection token, which users must inject by pressing a button.
   2. Other requests are made without a CSRF token.

I would prefer the second alternative, because it achieves the "other requests" case 2.2 with only one request where as case 1.2 requires two requests.