Sure. Any scenario where a browser-based app interacts with a backend, you’d have to different components (Frontend and backend). The backend can act as the OAuth client, and the frontend just handles views and api calls. This would be the exact scenario of the Browser-based Apps spec with a BFF.
Furthermore, any attack based on injecting malicious JS would fall into this category. An XSS attack would allow the attacker to provide data that becomes executable JS code when rendered in a browser. This can occur with any type of application, but would not grant the attacker control over the server-side runtime. Same goes for a compromised third-party JS file that is loaded in the browser with a script tag. Or if you build a SPA and one of the dependencies contains malicious code, the code will end up in the frontend, but will not be able to control the server-side environment. The original discussion started off with the capability to execute malicious JS within the app in the browser of the user. That type of attack is a lot less severe than an attacker controlling a server-side environment of a confidential client. Philippe > On 9 Nov 2025, at 13:02, Warren Parad <[email protected]> wrote: > > I don't think that's moving the goalposts, I think it is exactly the same > attack surface. I'm suggesting an attacker that has the capability to inject > a malicious iframe must also have access to the entire application including > compromising credential client secrets and an entire backend process making > any defense against iframes worthless as you pointed out. > > If you think I am moving the target, would you be able to share with me a > scenario where an attacker might only have access to inject an iframe, but > their strategy for compromise of the vulnerable attack surface would exclude > the ability to compromise a credentialed client runtime? > > On Sat, Nov 8, 2025 at 8:19 AM Philippe De Ryck > <[email protected] > <mailto:[email protected]>> wrote: >> Getting CSP right as a defence against XSS is far from impossible. Policies >> using nonces, hashes, and strict-dynamic work quite well in practice. >> >> I also noticed that you significantly moved the goal posts. The threat model >> went from injecting an iframe to steal an authorization code to controlling >> the generation of pages on the server-side (not only injecting content, but >> actively modifying or removing legitimate content). If the attacker has this >> much access to the application, tricking the user into completing a >> fraudulent OAuth flow is likely not the first thing on their mind, nor the >> most relevant one. >> >> Philippe >> >> >> >>> On 7 Nov 2025, at 11:20, Warren Parad <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> I was personally unaware of the implications of dynamically changing the >>> CSP in javascript in the user agent, but that actually isn't what I meant. >>> I do agree in practice getting a CSP right is a near impossible task, what >>> I was suggesting is that it is the only line of defense, not necessarily a >>> good one. >>> >>> If the application is compromised, then that compromise could be an SPA, >>> MPA, or SSR. That is the application architecture is relevant here. In the >>> case of an SPA or MPA, that means the javascript would have little control >>> over the CSP and thus the CSP offers complete control. >>> >>> However, in the case of a dynamic application, the CSP would be generated >>> on the server side, where the attacker has access, and then could alter the >>> html as they would with javascript in the user agent. In that scenario, the >>> only protection for the CSP would come from the separation of "application >>> source code" from "infrastructure", as security headers, such as the CSP, >>> are often configured and injected by components outside of the application >>> source where the third party dependency exists. >>> >>> So my thought is, there are no defenses available to block the attack >>> because it is in fact indistinguishable from legitimate usage unless we can >>> trust the agent that controls the transport mechanism. In the case we trust >>> the user agent and not the application source code, then the token exchange >>> must happen at the agent. If we don't trust the browser/user agent either, >>> then the oauth token exchange must happen at the OS level. A CSP often >>> exists between the user agent and the application code, so it enables us to >>> push the boundary of trust down a level. >>> >>> On Fri, Nov 7, 2025 at 7:45 AM Philippe De Ryck >>> <[email protected] >>> <mailto:[email protected]>> wrote: >>>> Just adding some context on CSP here, since it is often thrown out there >>>> as a solution for whatever is needed, which is unfortunately not the case. >>>> >>>> First of all, preventing data exfiltration with CSP is not a viable path >>>> to explore, since there are too many potential leaks in the browser. While >>>> this can be implemented as a “best effort” to raise the bar for an >>>> attacker, it is not something that can be prescribed as a best practice. >>>> >>>> Second, you are assuming that an attacker already has malicious JS >>>> running, but you’re also deploying CSP. The main goal of CSP is to prevent >>>> malicious code from executing in the first place, so that would already be >>>> a major failure of your CSP policy. To rely on CSP for more (e.g., >>>> preventing data exfil) is quite strange. >>>> >>>> Finally, I would be very surprised to learn about attacks modifying CSP >>>> policies from plain JS in a page (not a browser extension or other more >>>> privileged code). The attacker could remove meta tags, but AFAIK that >>>> won’t make the policy disappear. Modifying a policy set by a header is >>>> also not possible. And setting a new CSP from within JS will result in a >>>> second independent policy being evaluated. The original policies remain in >>>> place. Concretely, this would only allow a more restrictive policy, not >>>> the weakening of existing policies. >>>> >>>> So to summarize, CSP is extremely useful as a second line of defense >>>> against XSS, but is not going to be a solution to the issue at hand. >>>> >>>> Philippe >>>> >>>>> On 7 Nov 2025, at 00:18, Warren Parad <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> Thank you Chris for that summary, I think that makes it really clear what >>>>> the problem is. I appreciate it. Malicious control over the javascript >>>>> would allow the attacker to start an auth code exchange remotely >>>>> triggered by the user accessing the vulnerable page, causing the user to >>>>> log in, with the context generated by the attacker's authorization >>>>> request via likely window.location.assign. Then, there are of course ways >>>>> to prevent the auth code completion on redirect return to the app, where >>>>> the code can be exfiltrated to the attacker to complete the flow on their >>>>> side. >>>>> >>>>> It seems to me that token exchange might need to happen via the browser >>>>> directly instead of the app, in order to make sure it is protected from >>>>> tampering. As soon as we expect the application to complete the code >>>>> exchange it is vulnerable to the malicious code blocking the exchange. >>>>> And then being completed by the attacker. >>>>> >>>>> The only protection I can see here realistically is a Content Security >>>>> Policy (CSP), blocking the exfiltration of the authorization code. And >>>>> although an application that is compromised could dynamically change its >>>>> CSP it is much harder to also block the CSP generated by page response >>>>> headers (rather than HTML head meta tags). >>>>> >>>>> It's worth noting that since PAR and authorization requests could be >>>>> dynamically generated by the attacker at the moment any user interacts >>>>> with the compromised app, authorization code exchange lifetimes aren't a >>>>> defense mechanism, neither is PAR, or DPoP it seems. While they increase >>>>> the complexity of the attack, they won't remotely stop it. >>>>> >>>>> On Thu, Nov 6, 2025 at 11:54 PM Chris Keogh <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>>> Hi Jonas, so just to be clear: >>>>>> The attacker generates the private key for DPoP during their >>>>>> session/browser >>>>>> The attacker is able to insert the DPoP proof into the auth code flow >>>>>> started by the malicious javascript in the target's session/browser >>>>>> auth flow happens in the target session/browser, is broken by malicious >>>>>> js once the code is returned >>>>>> auth code exfiltrated to the attacker by malicious js >>>>>> attacker injects the code into their session and uses their private key >>>>>> created in step 1 to generate the correctly bound proof >>>>>> Have I got this correct? >>>>>> >>>>>> On Fri, 7 Nov 2025 at 11:17, <[email protected] >>>>>> <mailto:[email protected]>> wrote: >>>>>>> Send OAuth mailing list submissions to >>>>>>> [email protected] <mailto:[email protected]> >>>>>>> >>>>>>> To subscribe or unsubscribe via email, send a message with subject or >>>>>>> body 'help' to >>>>>>> [email protected] <mailto:[email protected]> >>>>>>> >>>>>>> You can reach the person managing the list at >>>>>>> [email protected] <mailto:[email protected]> >>>>>>> >>>>>>> When replying, please edit your Subject line so it is more specific >>>>>>> than "Re: Contents of OAuth digest..." >>>>>>> >>>>>>> Today's Topics: >>>>>>> >>>>>>> 1. Re: Question: Form Post Response Mode in OAuth/OIDC Security Best >>>>>>> Practices >>>>>>> (Primbs, Jonas) >>>>>>> >>>>>>> >>>>>>> ---------------------------------------------------------------------- >>>>>>> >>>>>>> Message: 1 >>>>>>> Date: Thu, 6 Nov 2025 22:15:54 +0000 >>>>>>> From: "Primbs, Jonas" <[email protected] >>>>>>> <mailto:[email protected]>> >>>>>>> Subject: [OAUTH-WG] Re: Question: Form Post Response Mode in >>>>>>> OAuth/OIDC Security Best Practices >>>>>>> To: Chris Keogh <[email protected] >>>>>>> <mailto:[email protected]>> >>>>>>> Cc: "[email protected] <mailto:[email protected]>" <[email protected] >>>>>>> <mailto:[email protected]>> >>>>>>> Message-ID: <[email protected] >>>>>>> <mailto:[email protected]>> >>>>>>> Content-Type: multipart/signed; >>>>>>> boundary="Apple-Mail=_B3DF460A-2551-4E22-8927-37A61004E7BB"; >>>>>>> protocol="application/pkcs7-signature"; micalg=sha-256 >>>>>>> >>>>>>> Hi Chris, >>>>>>> >>>>>>> a DPoP-bound authorization code will mitigate the CSRF attack. >>>>>>> >>>>>>> However, it will not mitigate a Browser-Swapping attack, because the >>>>>>> private key will be generated within the attacker’s session, the user >>>>>>> authenticates, calling the redirect URI fails, and the critical request >>>>>>> will be done afterwards within the attacker's session. >>>>>>> >>>>>>> Greetings, >>>>>>> Jonas >>>>>>> >>>>>>> >>>>>>> > Am 06.11.2025 um 16:38 schrieb Chris Keogh >>>>>>> > <[email protected] <mailto:[email protected]>>: >>>>>>> > >>>>>>> > Hi there, >>>>>>> > >>>>>>> > Trying to get my head around this attack, very likely I am missing >>>>>>> > something. >>>>>>> > >>>>>>> > Would not binding the auth code to a DPoP key help prevent this >>>>>>> > attack when the stolen code was injected by the attacker? Even if the >>>>>>> > attacker generates their own key material using malicious javascript >>>>>>> > within the target's session and exfiltrates that alongside the code, >>>>>>> > when the attacker attempts to inject the stolen code the BFF will try >>>>>>> > and redeem the code with its own DPoP proof. >>>>>>> > >>>>>>> > Regards, >>>>>>> > Chris >>>>>>> > >>>>>>> > On Fri, 7 Nov 2025 at 00:26, <[email protected] >>>>>>> > <mailto:[email protected]> <mailto:[email protected] >>>>>>> > <mailto:[email protected]>>> wrote: >>>>>>> >> Send OAuth mailing list submissions to >>>>>>> >> [email protected] <mailto:[email protected]> >>>>>>> >> <mailto:[email protected] <mailto:[email protected]>> >>>>>>> >> >>>>>>> >> To subscribe or unsubscribe via email, send a message with subject or >>>>>>> >> body 'help' to >>>>>>> >> [email protected] <mailto:[email protected]> >>>>>>> >> <mailto:[email protected] <mailto:[email protected]>> >>>>>>> >> >>>>>>> >> You can reach the person managing the list at >>>>>>> >> [email protected] <mailto:[email protected]> >>>>>>> >> <mailto:[email protected] <mailto:[email protected]>> >>>>>>> >> >>>>>>> >> When replying, please edit your Subject line so it is more specific >>>>>>> >> than "Re: Contents of OAuth digest..." >>>>>>> >> >>>>>>> >> Today's Topics: >>>>>>> >> >>>>>>> >> 1. Re: Question: Form Post Response Mode in OAuth/OIDC Security >>>>>>> >> Best Practices >>>>>>> >> (Andrey Kuznetsov) >>>>>>> >> 2. Re: Question: Form Post Response Mode in OAuth/OIDC Security >>>>>>> >> Best Practices >>>>>>> >> (Warren Parad) >>>>>>> >> >>>>>>> >> >>>>>>> >> ---------------------------------------------------------------------- >>>>>>> >> >>>>>>> >> Message: 1 >>>>>>> >> Date: Thu, 06 Nov 2025 14:06:43 +0300 >>>>>>> >> From: Andrey Kuznetsov <[email protected] >>>>>>> >> <mailto:[email protected]> >>>>>>> >> <mailto:[email protected] >>>>>>> >> <mailto:[email protected]>>> >>>>>>> >> Subject: [OAUTH-WG] Re: Question: Form Post Response Mode in >>>>>>> >> OAuth/OIDC Security Best Practices >>>>>>> >> To: Warren Parad <[email protected] <mailto:[email protected]> >>>>>>> >> <mailto:[email protected] <mailto:[email protected]>>> >>>>>>> >> Cc: "[email protected] <mailto:[email protected]> <mailto:[email protected] >>>>>>> >> <mailto:[email protected]>>" <[email protected] <mailto:[email protected]> >>>>>>> >> <mailto:[email protected] <mailto:[email protected]>>> >>>>>>> >> Message-ID: <[email protected] >>>>>>> >> <mailto:[email protected]> >>>>>>> >> <mailto:[email protected] >>>>>>> >> <mailto:[email protected]>>> >>>>>>> >> Content-Type: text/html; charset=utf-8 >>>>>>> >> >>>>>>> >> A message part incompatible with plain text digests has been removed >>>>>>> >> ... >>>>>>> >> Name: not available >>>>>>> >> Type: text/html >>>>>>> >> Size: 18752 bytes >>>>>>> >> Desc: not available >>>>>>> >> >>>>>>> >> ------------------------------ >>>>>>> >> >>>>>>> >> Message: 2 >>>>>>> >> Date: Thu, 6 Nov 2025 12:24:46 +0100 >>>>>>> >> From: Warren Parad <[email protected] <mailto:[email protected]> >>>>>>> >> <mailto:[email protected] <mailto:[email protected]>>> >>>>>>> >> Subject: [OAUTH-WG] Re: Question: Form Post Response Mode in >>>>>>> >> OAuth/OIDC Security Best Practices >>>>>>> >> To: Andrey Kuznetsov <[email protected] >>>>>>> >> <mailto:[email protected]> >>>>>>> >> <mailto:[email protected] >>>>>>> >> <mailto:[email protected]>>> >>>>>>> >> Cc: "[email protected] <mailto:[email protected]> <mailto:[email protected] >>>>>>> >> <mailto:[email protected]>>" <[email protected] <mailto:[email protected]> >>>>>>> >> <mailto:[email protected] <mailto:[email protected]>>> >>>>>>> >> Message-ID: >>>>>>> >> >>>>>>> >> <cajot-l3lmzpxuububh7bqfcxmcpwwocrncb6xxuvqt9qwmr...@mail.gmail.com >>>>>>> >> <mailto:cajot-l3lmzpxuububh7bqfcxmcpwwocrncb6xxuvqt9qwmr...@mail.gmail.com> >>>>>>> >> >>>>>>> >> <mailto:cajot-l3lmzpxuububh7bqfcxmcpwwocrncb6xxuvqt9qwmr...@mail.gmail.com >>>>>>> >> >>>>>>> >> <mailto:cajot-l3lmzpxuububh7bqfcxmcpwwocrncb6xxuvqt9qwmr...@mail.gmail.com>>> >>>>>>> >> Content-Type: multipart/alternative; >>>>>>> >> boundary="00000000000097d2c10642eb50fa" >>>>>>> >> >>>>>>> >> If an attacker can compromise the application running in the user >>>>>>> >> agent, >>>>>>> >> then from an OAuth2 standpoint there is no way to distinguish or >>>>>>> >> protect >>>>>>> >> the user from malicious requests made on the user's behalf. I think >>>>>>> >> the >>>>>>> >> problem here is that one assumption that's been made is that HTTP >>>>>>> >> Only >>>>>>> >> Cookies secure against your PreCondition #1 (XSS or compromised >>>>>>> >> dependency). But that was never the case, an attacker could always >>>>>>> >> make >>>>>>> >> requests on the user's behalf from inside the application. The >>>>>>> >> theoretical >>>>>>> >> value was preventing the exfiltration of the generated access tokens. >>>>>>> >> You've proven that's not the case, but realistically that's >>>>>>> >> irrelevant, >>>>>>> >> because it was never the requirement that HTTP Only Cookies could >>>>>>> >> protect >>>>>>> >> against XSS or a compromised dependency. >>>>>>> >> >>>>>>> >> If we want to protect against XSS and a compromised dependency, then >>>>>>> >> both >>>>>>> >> the generation of the access token and the access token itself have >>>>>>> >> to be >>>>>>> >> obscured from the application. Today, only the access token can be >>>>>>> >> controlled to be blocked, but the current state of the browsers is >>>>>>> >> that >>>>>>> >> there is no way to initiate and secure the token generation from a >>>>>>> >> compromised user agent application when the only technology >>>>>>> >> available is >>>>>>> >> the user agent. >>>>>>> >> >>>>>>> >> To solve there are two different solutions: >>>>>>> >> >>>>>>> >> 1. User Agents must support an OAuth2 first mechanism for the >>>>>>> >> secure >>>>>>> >> generation of PKCE. Right now, since the application is >>>>>>> >> responsible for >>>>>>> >> generation, this process can be compromised. >>>>>>> >> 2. The alternative would be to protect the flow, by restricting >>>>>>> >> the use >>>>>>> >> of the /authorize endpoint to Push Authorization Requests. By >>>>>>> >> limiting to a >>>>>>> >> Pushed Authorization Request (PAR) and not allowing the use of >>>>>>> >> authorize >>>>>>> >> endpoint to generate auth requests via the redirect, we can be >>>>>>> >> sure that an >>>>>>> >> credentialled client can roundtrip a secure client secret or even >>>>>>> >> with the >>>>>>> >> PKCE. >>>>>>> >> >>>>>>> >> With that regard, rather than client *response_modes* to limit >>>>>>> >> configuration, it feels more appropriate to add >>>>>>> >> *require_pushed_authorization_requests >>>>>>> >> *to the client metadata of the authorization server. >>>>>>> >> >>>>>>> >> By doing so we are moving the security out of the user agent into the >>>>>>> >> credentialed client. >>>>>>> >> >>>>>>> >> BUT! What good does this actually do? If we assume there could be an >>>>>>> >> XSS or >>>>>>> >> a compromised dependency in the application running in the browser, >>>>>>> >> then it >>>>>>> >> is trivially true that we should also expect a transferrable XSS >>>>>>> >> request or >>>>>>> >> compromised dependency in the credentialed client as well. Which >>>>>>> >> means that >>>>>>> >> all secrets and mechanisms available are vulnerable there. >>>>>>> >> >>>>>>> >> Which leads us back to the only way to secure the flow with these >>>>>>> >> assumptions would be to have a root of trust. That is, the >>>>>>> >> pre-registration >>>>>>> >> of public keys associated with the client. With that we are back to >>>>>>> >> DPoP: >>>>>>> >> https://datatracker.ietf.org/doc/html/rfc9449 >>>>>>> >> >>>>>>> >> While DPoP still cannot prevent the XSS or compromised dependency >>>>>>> >> from >>>>>>> >> allowing an attacker to utilize the tokens generated for the >>>>>>> >> browser, it >>>>>>> >> will absolutely prevent the type of attack since those tokens would >>>>>>> >> be >>>>>>> >> bound to the user agent. >>>>>>> >> >>>>>>> >> The conclusion here, is that we are back to the same two solutions: >>>>>>> >> >>>>>>> >> 1. User agents must support an OAuth2 first mechanism for the >>>>>>> >> sucer >>>>>>> >> generation of PKCE, preferably, DPoP. Right now since the >>>>>>> >> application is >>>>>>> >> responsible for the generation, this process can be compromised. >>>>>>> >> 2. If we can assume there are vulnerabilities somewhere, then we >>>>>>> >> should >>>>>>> >> also assume there are vulnerabilities everywhere, and that means >>>>>>> >> secrecy of >>>>>>> >> tokens in the browser is worthless because if a credentialed >>>>>>> >> client is >>>>>>> >> compromised, then so is the ability to secure HTTP communication >>>>>>> >> from that >>>>>>> >> client. >>>>>>> >> >>>>>>> >> I'm 100% for having a browser supported DPoP mechanism for the bound >>>>>>> >> generation of access tokens. That for me is the only viable path >>>>>>> >> forward >>>>>>> >> for this issue and has been brought up multiple times in the DBSC >>>>>>> >> implementation concerns. But I just don't see how any changes to the >>>>>>> >> OAuth2 >>>>>>> >> protocol can help here. >>>>>>> >> >>>>>>> >> I hope I'm making at least a little sense. >>>>>>> >> - Warren >>>>>>> >> >>>>>>> >> On Thu, Nov 6, 2025 at 12:06 PM Andrey Kuznetsov >>>>>>> >> <[email protected] <mailto:[email protected]> >>>>>>> >> <mailto:[email protected] >>>>>>> >> <mailto:[email protected]>>> >>>>>>> >> wrote: >>>>>>> >> >>>>>>> >> > Sure. The preconditions are: >>>>>>> >> > >>>>>>> >> > 1. Execution of malicious JavaScript code within the context of >>>>>>> >> > one of the >>>>>>> >> > application’s pages with the same origin. Such as >>>>>>> >> > - Cross-Site Scripting (XSS) >>>>>>> >> > - A vulnerable or compromised dependency, or third-party script >>>>>>> >> > 2. The ability to obtain the parameters of the authorization >>>>>>> >> > response: >>>>>>> >> > - Using the web message response mode and setting up one’s own >>>>>>> >> > event >>>>>>> >> > listener >>>>>>> >> > - Injecting an invisible iframe and obtaining the authorization >>>>>>> >> > response >>>>>>> >> > from the location object + *breaking the OAuth flow* >>>>>>> >> > - Briefly opening a new window and obtaining the authorization >>>>>>> >> > response >>>>>>> >> > from the location object + *breaking the OAuth flow* >>>>>>> >> > 3. Breaking the OAuth flow. To break the OAuth flow means to >>>>>>> >> > prevent the >>>>>>> >> > authorization response parameters (such as the authorization code) >>>>>>> >> > from >>>>>>> >> > being received and consumed by the application itself. This can be >>>>>>> >> > achieved >>>>>>> >> > by >>>>>>> >> > - Passing an invalid state value >>>>>>> >> > - Changing the response type/response mode for the >>>>>>> >> > authorization request >>>>>>> >> > - Case-shifting the redirect URI value >>>>>>> >> > - Path extension for the redirect URI value >>>>>>> >> > - Adding query parameters to the redirect URI value >>>>>>> >> > - Using previously added, but forgotten valid values for the >>>>>>> >> > redirect >>>>>>> >> > URI >>>>>>> >> > 4. SSO mechanism and seamless user authorization. The user must >>>>>>> >> > have an >>>>>>> >> > active session on the authorization server, so that the >>>>>>> >> > authentication form >>>>>>> >> > is not returned in response to the authorization request. >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > ---------------- >>>>>>> >> > Кому: Andrey Kuznetsov ([email protected] >>>>>>> >> > <mailto:[email protected]> >>>>>>> >> > <mailto:[email protected] >>>>>>> >> > <mailto:[email protected]>>); >>>>>>> >> > Копия: Philippe De Ryck ([email protected] >>>>>>> >> > <mailto:[email protected]> >>>>>>> >> > <mailto:[email protected] >>>>>>> >> > <mailto:[email protected]>>), >>>>>>> >> > [email protected] <mailto:[email protected]> <mailto:[email protected] >>>>>>> >> > <mailto:[email protected]>>; >>>>>>> >> > Тема: [OAUTH-WG] Re: Question: Form Post Response Mode in >>>>>>> >> > OAuth/OIDC >>>>>>> >> > Security Best Practices; >>>>>>> >> > 06.11.2025, 13:41, "Warren Parad" <[email protected] >>>>>>> >> > <mailto:[email protected]> <mailto:[email protected] >>>>>>> >> > <mailto:[email protected]>>>: >>>>>>> >> > >>>>>>> >> > I'm using the word "assumption", and you've used the word >>>>>>> >> > "precondition", >>>>>>> >> > that's fine, but it doesn't clarify the situation. Can you state >>>>>>> >> > what >>>>>>> >> > "preconditions" you are expecting here? >>>>>>> >> > >>>>>>> >> > On Thu, Nov 6, 2025 at 11:30 AM Andrey Kuznetsov < >>>>>>> >> > [email protected] <mailto:[email protected]> >>>>>>> >> > <mailto:[email protected] >>>>>>> >> > <mailto:[email protected]>>> wrote: >>>>>>> >> > >>>>>>> >> > Philippe, >>>>>>> >> > Yes, i suppose, i do. >>>>>>> >> > I have a short video demonstration <https://youtu.be/AFsrm02tC6c> >>>>>>> >> > for the >>>>>>> >> > described attack. Also there is another demo >>>>>>> >> > <https://youtu.be/asEBPOs9ys8> for the same attack but done >>>>>>> >> > manually for >>>>>>> >> > clarity. >>>>>>> >> > The source code for applications used in those examples is >>>>>>> >> > available on >>>>>>> >> > GitHub <https://github.com/anador/oauth-demo-poc>. The app may >>>>>>> >> > take some >>>>>>> >> > setup but can be used with any OAuth/OIDC-compatible authorization >>>>>>> >> > server. >>>>>>> >> > >>>>>>> >> > Warren, >>>>>>> >> > Perhaps, i may misunderstand your questions, but with the necessary >>>>>>> >> > preconditions met it's not an assumption, but a statement. >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > ---------------- >>>>>>> >> > Кому: Philippe De Ryck ([email protected] >>>>>>> >> > <mailto:[email protected]> >>>>>>> >> > <mailto:[email protected] >>>>>>> >> > <mailto:[email protected]>>); >>>>>>> >> > Копия: [email protected] <mailto:[email protected]> >>>>>>> >> > <mailto:[email protected] <mailto:[email protected]>>; >>>>>>> >> > Тема: [OAUTH-WG] Re: Question: Form Post Response Mode in >>>>>>> >> > OAuth/OIDC >>>>>>> >> > Security Best Practices; >>>>>>> >> > 06.11.2025, 12:46, "Warren Parad" <[email protected] >>>>>>> >> > <mailto:[email protected]> <mailto:[email protected] >>>>>>> >> > <mailto:[email protected]>>>: >>>>>>> >> > >>>>>>> >> > Would someone be able to state the obvious for me? >>>>>>> >> > >>>>>>> >> > Is the assumption that there is a code injection attack present >>>>>>> >> > where an >>>>>>> >> > attacker has access to javascript running in the application's >>>>>>> >> > interface? >>>>>>> >> > Is that the core assumption or is it something else? >>>>>>> >> > >>>>>>> >> > On Thu, Nov 6, 2025 at 8:18 AM Philippe De Ryck < >>>>>>> >> > [email protected] >>>>>>> >> > <mailto:[email protected]> >>>>>>> >> > <mailto:[email protected] >>>>>>> >> > <mailto:[email protected]>>> wrote: >>>>>>> >> > >>>>>>> >> > Hi Andrey, >>>>>>> >> > >>>>>>> >> > It seems that with this high degree of control, the attacker would >>>>>>> >> > indeed >>>>>>> >> > be able to manipulate the flows. >>>>>>> >> > >>>>>>> >> > However, I’m curious to know if you have an actual working demo of >>>>>>> >> > step >>>>>>> >> > 9-10-11. I remember from a private discussion a while ago that >>>>>>> >> > someone >>>>>>> >> > pointed out that intermediate redirects are not observable in the >>>>>>> >> > browser. >>>>>>> >> > So if response 9 triggers a redirect to the backend (10), and the >>>>>>> >> > backend >>>>>>> >> > handles it and then redirects back to the main application (as a >>>>>>> >> > BFF would >>>>>>> >> > do), then the request in 10 is not observable from JS, and would >>>>>>> >> > prevent an >>>>>>> >> > attacker from stealing the authz code. >>>>>>> >> > >>>>>>> >> > Kind regards >>>>>>> >> > >>>>>>> >> > Philippe >>>>>>> >> > >>>>>>> >> > — >>>>>>> >> > *Pragmatic Web Security* >>>>>>> >> > *Security for developers* >>>>>>> >> > https://pragmaticwebsecurity.com/ >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > On 6 Nov 2025, at 06:33, Andrey Kuznetsov >>>>>>> >> > <[email protected] <mailto:[email protected]> >>>>>>> >> > <mailto:[email protected] >>>>>>> >> > <mailto:[email protected]>>> >>>>>>> >> > wrote: >>>>>>> >> > >>>>>>> >> > I'm sorry for the delayed response. >>>>>>> >> > >>>>>>> >> > *Filip*, i agree with your statements and you provided reasonable >>>>>>> >> > examples of cookie that might be needed on the request to the >>>>>>> >> > redirect URI. >>>>>>> >> > >>>>>>> >> > There is also a reply from *Dick *with the similar reasoning: >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > *As Filip stated, cookies are the main reason. There is almost >>>>>>> >> > always >>>>>>> >> > some session state that the app wants to maintain between making >>>>>>> >> > the >>>>>>> >> > authorization request and getting the authorization response. It >>>>>>> >> > can be as >>>>>>> >> > simple as where the user was in the app so they are redirected to >>>>>>> >> > the >>>>>>> >> > original place, to what is already in the shopping cart, or even >>>>>>> >> > existing >>>>>>> >> > authentication context as the user is linking another account. >>>>>>> >> > With the use >>>>>>> >> > of PKCE, the threats of intercepted query parameters are >>>>>>> >> > reduced.If we were >>>>>>> >> > to make a recommendation, it would be the redirect and not form >>>>>>> >> > post as >>>>>>> >> > session hijacking is the larger threat now from my understanding.* >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > Also there's been another thread started about Browser Swapping >>>>>>> >> > attack >>>>>>> >> > which discusses the related topic. However, i would like to clear >>>>>>> >> > things up. >>>>>>> >> > 1. There is a real attack scenario in which the attacker can steal >>>>>>> >> > the >>>>>>> >> > authorization code from the user's browser and use it even if the >>>>>>> >> > client >>>>>>> >> > implements confidential client, PKCE, state and nonce (please, >>>>>>> >> > consult the >>>>>>> >> > diagram 1.png attached) >>>>>>> >> > 2. The ways of authorization code stealing are not hypothetical or >>>>>>> >> > ephemeral: basically it can be done if the attacker is able to >>>>>>> >> > execute JS >>>>>>> >> > on any page of the legitimate application that has an origin >>>>>>> >> > matching the >>>>>>> >> > origin of the redirect URI . Full preconditions are listed here >>>>>>> >> > <https://medium.com/@anador/attacks-via-a-new-oauth-flow-authorization-code-injection-and-whether-httponly-pkce-and-bff-3db1624b4fa7#cd2e> >>>>>>> >> > . >>>>>>> >> > 3. The only complete mitigation for the attack is form post >>>>>>> >> > response mode >>>>>>> >> > (please, consult the diagram 2.png attached). Other additional >>>>>>> >> > mitigations >>>>>>> >> > are listed here >>>>>>> >> > <https://medium.com/@anador/attacks-via-a-new-oauth-flow-authorization-code-injection-and-whether-httponly-pkce-and-bff-3db1624b4fa7#6da0> >>>>>>> >> > . >>>>>>> >> > 4. The attack is possible because of the nature of OAuth flows >>>>>>> >> > (please, >>>>>>> >> > consult the diagram 3.png attached). All additional protection >>>>>>> >> > measures >>>>>>> >> > such as PAR/JAR/JARM don’t prevent the attack. >>>>>>> >> > 4. When we use query/fragment/web message response modes we cannot >>>>>>> >> > prevent >>>>>>> >> > the attacker that executes JS on the app's origin from accessing >>>>>>> >> > the >>>>>>> >> > authorization response. However, form post response mode does not >>>>>>> >> > allow >>>>>>> >> > access to the authorization response from the origin of the >>>>>>> >> > application >>>>>>> >> > itself. But the authorization server must be able to limit the >>>>>>> >> > available >>>>>>> >> > response modes at some level. >>>>>>> >> > >>>>>>> >> > On the other hand we have downsides of using form post response >>>>>>> >> > mode: if >>>>>>> >> > we need cookies to be received on the redirect URI page, those >>>>>>> >> > cookies (not >>>>>>> >> > actual session cookies!) must have SameSite=None attribute. I >>>>>>> >> > agree that >>>>>>> >> > for some cases it can be crucial, but for some it can add no risks. >>>>>>> >> > Also close attention should be paid to the values of the redirect >>>>>>> >> > URI that >>>>>>> >> > the authorization server considers valid to prevent XSS at the AS >>>>>>> >> > side. >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > I suggest we should point out that form post response mode >>>>>>> >> > protects from >>>>>>> >> > the stated attack, while it should be considered if CSRF at >>>>>>> >> > client's side >>>>>>> >> > is going to be possible because of marking some cookies with >>>>>>> >> > SameSite=None. >>>>>>> >> > >>>>>>> >> > ---------------- >>>>>>> >> > Кому: Andrey Kuznetsov ([email protected] >>>>>>> >> > <mailto:[email protected]> >>>>>>> >> > <mailto:[email protected] >>>>>>> >> > <mailto:[email protected]>>); >>>>>>> >> > Копия: [email protected] <mailto:[email protected]> >>>>>>> >> > <mailto:[email protected] <mailto:[email protected]>>; >>>>>>> >> > Тема: [OAUTH-WG] Re: Question: Form Post Response Mode in >>>>>>> >> > OAuth/OIDC >>>>>>> >> > Security Best Practices; >>>>>>> >> > 26.10.2025, 10:54, "Filip Skokan" <[email protected] >>>>>>> >> > <mailto:[email protected]> <mailto:[email protected] >>>>>>> >> > <mailto:[email protected]>>>: >>>>>>> >> > >>>>>>> >> > > That is why I emphasized "significant". >>>>>>> >> > >>>>>>> >> > Are they not significant? >>>>>>> >> > >>>>>>> >> > I may not have read your blog post but i did read and quote the >>>>>>> >> > question I >>>>>>> >> > was answering to. While these may appear as insignificant reasons >>>>>>> >> > at first >>>>>>> >> > glance they are both blockers encountered at one point in time in >>>>>>> >> > my past >>>>>>> >> > experience. >>>>>>> >> > >>>>>>> >> > > sameSite >>>>>>> >> > >>>>>>> >> > Account Linking, Step-up, re-auth, site preferences, shopping >>>>>>> >> > carts are >>>>>>> >> > all scenarios where you want/need an existing session loaded >>>>>>> >> > (regardless >>>>>>> >> > whether it's preauth or not). >>>>>>> >> > >>>>>>> >> > > FOUC >>>>>>> >> > >>>>>>> >> > User agent that's processing a 30x response with a location header >>>>>>> >> > and a >>>>>>> >> > 200 that contains a JS self-submitting form is different when it >>>>>>> >> > comes to >>>>>>> >> > FOUC. Of course this problem is exaggerated on unstable or slow >>>>>>> >> > connections >>>>>>> >> > such as mobile. >>>>>>> >> > >>>>>>> >> > - Filip >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > 25. 10. 2025 v 17:50, Andrey Kuznetsov >>>>>>> >> > <[email protected] <mailto:[email protected]> >>>>>>> >> > <mailto:[email protected] >>>>>>> >> > <mailto:[email protected]>>>: >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > That is why I emphasized "significant". >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > UX - FOUC or briefly displayed submit page at the AS when it's >>>>>>> >> > sending >>>>>>> >> > responses >>>>>>> >> > >>>>>>> >> > - The returning page with the autosubmitted form usually does not >>>>>>> >> > contain >>>>>>> >> > any explicit content. In fact, I'm not sure how it's different >>>>>>> >> > from any >>>>>>> >> > redirect URI page that might appear briefly, as you mentioned, >>>>>>> >> > when other >>>>>>> >> > response modes are in use >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > sameSite - the client is required to use sameSite=none for the >>>>>>> >> > cookies >>>>>>> >> > they expect to load at the redirect_uri, that may include session >>>>>>> >> > related >>>>>>> >> > cookies for which sameSite=none is the exact opposite of what they >>>>>>> >> > should >>>>>>> >> > strive for. >>>>>>> >> > >>>>>>> >> > - I agree with the first part of your statement, that's true. >>>>>>> >> > However, we >>>>>>> >> > should define what we mean by a "session" here and determine if >>>>>>> >> > it's a >>>>>>> >> > problem. Usually, this applies only to certain cookies that are >>>>>>> >> > used to >>>>>>> >> > maintain a "pre-auth session" and for such a case I'm not sure if >>>>>>> >> > it's a >>>>>>> >> > significant issue. I considered this nuance in the research i >>>>>>> >> > mentioned >>>>>>> >> > previously and explicitly stated that constraint. Could you share >>>>>>> >> > your >>>>>>> >> > example, If you have another case where we do need a cookie to be >>>>>>> >> > sent to >>>>>>> >> > the redirect URI endpoint? >>>>>>> >> > ---------------- >>>>>>> >> > Кому: Andrey Kuznetsov ([email protected] >>>>>>> >> > <mailto:[email protected]> >>>>>>> >> > <mailto:[email protected] >>>>>>> >> > <mailto:[email protected]>>); >>>>>>> >> > Копия: [email protected] <mailto:[email protected]> >>>>>>> >> > <mailto:[email protected] <mailto:[email protected]>>; >>>>>>> >> > Тема: [OAUTH-WG] Re: Question: Form Post Response Mode in >>>>>>> >> > OAuth/OIDC >>>>>>> >> > Security Best Practices; >>>>>>> >> > 25.10.2025, 16:40, "Filip Skokan" <[email protected] >>>>>>> >> > <mailto:[email protected]> <mailto:[email protected] >>>>>>> >> > <mailto:[email protected]>>>: >>>>>>> >> > >>>>>>> >> > On the other hand, i cannot identify any significant drawbacks to >>>>>>> >> > using >>>>>>> >> > this response mode, aside from inconsistent support across >>>>>>> >> > implementations. >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > What about >>>>>>> >> > - UX - FOUC or briefly displayed submit page at the AS when it's >>>>>>> >> > sending >>>>>>> >> > responses >>>>>>> >> > - sameSite - the client is required to use sameSite=none for the >>>>>>> >> > cookies >>>>>>> >> > they expect to load at the redirect_uri, that may include session >>>>>>> >> > related >>>>>>> >> > cookies for which sameSite=none is the exact opposite of what they >>>>>>> >> > should >>>>>>> >> > strive for. >>>>>>> >> > >>>>>>> >> > - Filip >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > 25. 10. 2025 v 15:21, Andrey Kuznetsov >>>>>>> >> > <[email protected] <mailto:[email protected]> >>>>>>> >> > <mailto:[email protected] >>>>>>> >> > <mailto:[email protected]>>>: >>>>>>> >> > >>>>>>> >> > On the other hand, i cannot identify any significant drawbacks to >>>>>>> >> > using >>>>>>> >> > this response mode, aside from inconsistent support across >>>>>>> >> > implementations. >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > _______________________________________________ >>>>>>> >> > OAuth mailing list -- [email protected] <mailto:[email protected]> >>>>>>> >> > <mailto:[email protected] <mailto:[email protected]>> >>>>>>> >> > To unsubscribe send an email to [email protected] >>>>>>> >> > <mailto:[email protected]> <mailto:[email protected] >>>>>>> >> > <mailto:[email protected]>> >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > -- >>>>>>> >> > Best regards, >>>>>>> >> > Andrey Kuznetsov >>>>>>> >> > Software Architect >>>>>>> >> > Identity & Access Management >>>>>>> >> > Yandex Cloud >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > , >>>>>>> >> > >>>>>>> >> > _______________________________________________ >>>>>>> >> > OAuth mailing list -- [email protected] <mailto:[email protected]> >>>>>>> >> > <mailto:[email protected] <mailto:[email protected]>> >>>>>>> >> > To unsubscribe send an email to [email protected] >>>>>>> >> > <mailto:[email protected]> <mailto:[email protected] >>>>>>> >> > <mailto:[email protected]>> >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > -- >>>>>>> >> > Best regards, >>>>>>> >> > Andrey Kuznetsov >>>>>>> >> > Software Architect >>>>>>> >> > Identity & Access Management >>>>>>> >> > Yandex Cloud >>>>>>> >> > >>>>>>> >> > <1.png><2.png><3.png>_______________________________________________ >>>>>>> >> > OAuth mailing list -- [email protected] <mailto:[email protected]> >>>>>>> >> > <mailto:[email protected] <mailto:[email protected]>> >>>>>>> >> > To unsubscribe send an email to [email protected] >>>>>>> >> > <mailto:[email protected]> <mailto:[email protected] >>>>>>> >> > <mailto:[email protected]>> >>>>>>> >> > >>>>>>> >> > _______________________________________________ >>>>>>> >> > OAuth mailing list -- [email protected] <mailto:[email protected]> >>>>>>> >> > <mailto:[email protected] <mailto:[email protected]>> >>>>>>> >> > To unsubscribe send an email to [email protected] >>>>>>> >> > <mailto:[email protected]> <mailto:[email protected] >>>>>>> >> > <mailto:[email protected]>> >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > -- >>>>>>> >> > С уважением, >>>>>>> >> > Андрей Кузнецов >>>>>>> >> > Архитектор, YC IAM & Resource Management >>>>>>> >> > TG: @andreukuznetsov_work <https://t.me/andreukuznetsov_work> >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > -- >>>>>>> >> > С уважением, >>>>>>> >> > Андрей Кузнецов >>>>>>> >> > Архитектор, YC IAM & Resource Management >>>>>>> >> > TG: @andreukuznetsov_work <https://t.me/andreukuznetsov_work> >>>>>>> >> > >>>>>>> >> > >>>>>>> >> -------------- next part -------------- >>>>>>> >> A message part incompatible with plain text digests has been removed >>>>>>> >> ... >>>>>>> >> Name: not available >>>>>>> >> Type: text/html >>>>>>> >> Size: 23783 bytes >>>>>>> >> Desc: not available >>>>>>> >> >>>>>>> >> ------------------------------ >>>>>>> >> >>>>>>> >> Subject: Digest Footer >>>>>>> >> >>>>>>> >> _______________________________________________ >>>>>>> >> OAuth mailing list -- [email protected] <mailto:[email protected]> >>>>>>> >> <mailto:[email protected] <mailto:[email protected]>> >>>>>>> >> To unsubscribe send an email to [email protected] >>>>>>> >> <mailto:[email protected]> <mailto:[email protected] >>>>>>> >> <mailto:[email protected]>> >>>>>>> >> >>>>>>> >> >>>>>>> >> ------------------------------ >>>>>>> >> >>>>>>> >> End of OAuth Digest, Vol 205, Issue 29 >>>>>>> >> ************************************** >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > -- >>>>>>> > Chris Keogh >>>>>>> > Ph 021 1616692 >>>>>>> > _______________________________________________ >>>>>>> > OAuth mailing list -- [email protected] <mailto:[email protected]> >>>>>>> > To unsubscribe send an email to [email protected] >>>>>>> > <mailto:[email protected]> >>>>>>> >>>>>>> -------------- next part -------------- >>>>>>> A message part incompatible with plain text digests has been removed ... >>>>>>> Name: not available >>>>>>> Type: text/html >>>>>>> Size: 27498 bytes >>>>>>> Desc: not available >>>>>>> -------------- next part -------------- >>>>>>> A message part incompatible with plain text digests has been removed ... >>>>>>> Name: smime.p7s >>>>>>> Type: application/pkcs7-signature >>>>>>> Size: 6195 bytes >>>>>>> Desc: not available >>>>>>> >>>>>>> ------------------------------ >>>>>>> >>>>>>> Subject: Digest Footer >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list -- [email protected] <mailto:[email protected]> >>>>>>> To unsubscribe send an email to [email protected] >>>>>>> <mailto:[email protected]> >>>>>>> >>>>>>> >>>>>>> ------------------------------ >>>>>>> >>>>>>> End of OAuth Digest, Vol 205, Issue 43 >>>>>>> ************************************** >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Chris Keogh >>>>>> Ph 021 1616692 >>>>>> _______________________________________________ >>>>>> OAuth mailing list -- [email protected] <mailto:[email protected]> >>>>>> To unsubscribe send an email to [email protected] >>>>>> <mailto:[email protected]> >>>>> _______________________________________________ >>>>> OAuth mailing list -- [email protected] <mailto:[email protected]> >>>>> To unsubscribe send an email to [email protected] >>>>> <mailto:[email protected]> >>>> >>
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
