Please keep in mind that these referrer removing standards are relatively new and do not work in older browsers. Sensitive data of any kind in URL’s is still a very basic insecure coding practice and has no place in standards. Check out caniuse for how fractured support is for even modern browsers. IE, Edge and Safari iOS still have only partial support.
-- Jim Manico @Manicode Secure Coding Education +1 (808) 652-3805 > On Dec 9, 2018, at 9:23 AM, Filip Skokan <panva...@gmail.com> wrote: > > As David suggested, > > it is easier to get rid of the code from a query using a referrer policy > header or a meta than getting rid of a fragment which would require the each > client to have a javascript snippet rewriting the current window.location.hash > > S pozdravem, > Filip Skokan > > >> On Sun, Dec 9, 2018 at 2:53 PM Brock Allen <brockal...@gmail.com> wrote: >> Yes, I meant response_mode. Thanks. >> >> And those are good points about the referrer policy. Thanks for that insight >> as well. >> >> In the context of this thread/topic, I'm assuming browser-based JS clients, >> and a common deployment is from a CDN, so I suspect the <meta> tag approach >> for a referrer policy is sufficient (especially since many SPAs are designed >> for CDN deployment)? >> >> -Brock >> >>> On 12/9/2018 3:00:23 AM, David Waite <da...@alkaline-solutions.com> wrote: >>> >>> I assume the original post meant response_mode, not response_type. >>> >>> Fragments have their own data leakage problems, in particular they are >>> preserved on 3xx redirects (per >>> https://tools.ietf.org/html/rfc7231#section-7..1.2). The form_post mode is >>> the safest, but unfortunately was not defined in the original >>> specifications so it doesn’t have as widespread support. >>> >>> In the absence of a response_mode RFC, I would typically suggest both >>> killing the code in the referrer as part of processing, and a server-wide >>> Referrer Policy of never or origin (as those have reasonably broad support) >>> as server-wide response headers are easier to operationally audit. >>> >>> -DW >>> >>>> On Dec 8, 2018, at 3:53 PM, Brock Allen <brockal...@gmail.com> wrote: >>>> >>>> Not pure OAuth. This only came up as a question while I was implementing >>>> code flow/pkce for oidc-client-js. >>>> >>>> I can appreciate not expanding the current OAuth2 behavior in the BCP, so >>>> that's fair. I only wanted to mention it in case it had not been >>>> considered. >>>> >>>> Having said that, I think I will implement an optional response_type in my >>>> code flow/pkce to allow fragment, but default to query (as that's the >>>> default for pure code flow). >>>> >>>> -Brock >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
