After a lot of back and forth in the comments with OP and @mentallurg, this question finally makes sense. OP has a system where the user starts some process at SPA A, then SPA A causes the user's browser to make a GET request to the server hosting SPA B, in order to redirect the user to SPA B, where the user completes the process. Information from the user's session with SPA A is included in this GET request, so that this information is transferred from SPA A to SPA B.
OP wants to ensure that the user actually starts the process at SPA A first, before completing the process at SPA B. This is to thwart an attack where an attacker starts the process at SPA A, then lures the user to the attacker's site (perhaps by phishing), then uses a 302 redirect to cause the user to make the same GET request to SPA B that the attacker would have made had the attacker completed the process himself. By doing this, the attacker dupes to the user into completing the second step of the process at SPA B, using information that the attacker 'planted' in the first step of the process at SPA A.
[Note: Part of the confusion around this question stems from the use of terms like 'MITM' and 'end-to-end' in ways that these terms are not normally used in information security.]
hacks workarounds to get around this, if it's possible for SPA A page to include some content from the domain that serves SPA B. See https://stackoverflow.com/questions/6761415/how-to-set-a-cookie-for-another-domain for some ideas around this.
As another way of getting around this, some sites use browser fingerprinting to track users from site to site. But, this is considered controversial, and is not recommended.
Perhaps a simple and non-invasive solution is to simply to ask the user for some secret that an attacker would not know when the user starts the process at SPA A (e.g. 'what city were you born in?'). Then, cryptographically tangle this secret in the GET request that takes the user from SPA A to SPA B. Then, ask the user to provide the same secret when he gets to SPA B, then verify that this secret is the one tangled in the GET request.