Problem
The consent-flow cookies (auth_method, *_redirect_url) are set with SameSite=Lax:
// internal/apigw/httpserver/endpoints_oauth.go ~L173
c.SetSameSite(http.SameSiteLaxMode)
Lax mode allows cookies to be sent on top-level GET navigations from external sites. An external site could link a user to /authorization/consent and the browser would send the existing consent cookies, potentially enabling CSRF-style attacks on the authorization flow.
SameSite=Strict would prevent cookies from being sent on any cross-site navigation, providing better CSRF protection for this sensitive auth context.
Why it is deferred
Changing to Strict requires careful evaluation of the SAML and OIDC redirect flows:
-
SAML POST binding: The IdP POSTs the SAML Response to the ACS endpoint. If the ACS endpoint needs cookies (it currently does not, since it uses the SAML session cache keyed by RelayState), Strict would block them on this cross-site POST.
-
OIDC redirect: The OP redirects back to /oidcrp/callback via a 302. The callback endpoint is registered outside the session middleware (rgRoot), so it does not need cookies. However, it redirects to /authorization/consent/#/credentials — if Strict blocks cookies on this redirect chain, the consent page would lose context.
-
PID auth: The redirect back from the verifier needs to be tested with Strict cookies.
Proposed approach
- Map out the full cookie lifecycle for each auth method (PID, SAML, OIDC)
- Identify which cross-site navigations carry cookies
- Test
Strict mode end-to-end with each auth method
- If
Strict breaks any flow, consider a hybrid approach: Strict for auth_method, Lax for redirect URLs
Impact
OWASP A01:2021 — Broken Access Control — reduced CSRF protection on authorization flow.
References
Problem
The consent-flow cookies (
auth_method,*_redirect_url) are set withSameSite=Lax:Laxmode allows cookies to be sent on top-level GET navigations from external sites. An external site could link a user to/authorization/consentand the browser would send the existing consent cookies, potentially enabling CSRF-style attacks on the authorization flow.SameSite=Strictwould prevent cookies from being sent on any cross-site navigation, providing better CSRF protection for this sensitive auth context.Why it is deferred
Changing to
Strictrequires careful evaluation of the SAML and OIDC redirect flows:SAML POST binding: The IdP POSTs the SAML Response to the ACS endpoint. If the ACS endpoint needs cookies (it currently does not, since it uses the SAML session cache keyed by RelayState),
Strictwould block them on this cross-site POST.OIDC redirect: The OP redirects back to
/oidcrp/callbackvia a 302. The callback endpoint is registered outside the session middleware (rgRoot), so it does not need cookies. However, it redirects to/authorization/consent/#/credentials— ifStrictblocks cookies on this redirect chain, the consent page would lose context.PID auth: The redirect back from the verifier needs to be tested with
Strictcookies.Proposed approach
Strictmode end-to-end with each auth methodStrictbreaks any flow, consider a hybrid approach:Strictforauth_method,Laxfor redirect URLsImpact
OWASP A01:2021 — Broken Access Control — reduced CSRF protection on authorization flow.
References