- changed component to FAPI2: Baseline
303 should be used
Section 2.2.1 point 18 says:
shall not use the HTTP 307 status code when redirecting a request that contains user credentials to avoid forwarding the credentials to a third party accidentally (see section 4.11 of [I-D.ietf-oauth-security-topics])
This should be updated, IMO, to:
shall not use the HTTP 307 status code when redirecting a request that contains user credentials to avoid forwarding the credentials to a third party accidentally (see section 4.11 of [I-D.ietf-oauth-security-topics]); should use the HTTP 303 status code when redirecting the user agent using status codes.
Rationale:
The only HTTP redirect code unambiguously defined to drop the the body of an HTTP POST request is a 303.
https://blog.acolyer.org/2016/11/07/a-comprehensive-formal-security-analysis-of-oauth-2-0/
Comments (10)
-
reporter -
307 is the only 3xx status known to relay the body of a request after IIRC modern browsers implement 302 handling as if it was a 303 already.
I believe the language should reflect the security-topics BCP - if there’s the need it would be updated there first.
-
reporter So, a financial-grade security specification should only echo some other security BCP and not define anything additional?
Are browsers the only user agent the spec cares about? Why rely on an ad-hoc standard based on common browser behavior?
-
After thinking a bit more about this, maybe FAPI is the right place to give more concrete advice here. After all, we’re doing that in many places of the spec.
-
If FAPI 2.0 recommends specific HTTP status codes (e.g.
303
) instead of prohibiting some (i.e.307
), it also should be taken into consideration that the examples in RFC 6749 are using302
. -
@daniel @taka what do you think of Travis' suggested wording?
-
I wouldn’t disagree if asked. (I don’t have enough expertise in the area, sorry.)
-
-
- changed status to resolved
PR merged
-
- changed component to FAPI2: Security Profile
- Log in to comment