I have two fastapi websites hosted on app.mydomain and login.mydomain which interact to authenticate the user and display the application. A react page loaded from app.mydomain issues a request to login.mydomain which returns a redirect response navigating to app.mydomain which triggers a CORS preflight check on app.mydomain. In this request the browser (Chrome 131.0) hides the ORIGIN header which should show login.mydomain (or app.mydomain for that matter, I don't care) and sends the value "null" instead (for privacy reasons). This causes app.mydomain to respond incorrectly (actual response varies based on implementation) and the login handshake fails.
I've tested both CORSMiddleware by starlette and the enable-cors annotation on the k8s nginx ingress, (understandably) neither supports the "null" origin: When using enable cors annotation the response says method not allowed (because nginx does not capture the preflight request and it is answered instead by the fastapi backend with 405 Method Not Allowed since the endpoint is "GET" only), and when using the CORS Middleware the response is 400 Bad Request (since it is not configured to support the "null" origin).
As I understand the "null" value is non-negotiable and so the only recourse for me is to accept "null" as an allowed origin which would cause app.mydomain to respond correctly and process the login response from login.mydomain.
I have two fastapi websites hosted on app.mydomain.com and login.mydomain.com which interact to authenticate the user and display the application. A react page loaded from app.mydomain.com issues a request to login.mydomain.com which returns a redirect response navigating to app.mydomain.com which triggers a CORS preflight check on app.mydomain.com. In this request the browser (Chrome 131.0) hides the ORIGIN header which should show login.mydomain.com (or app.mydomain.com for that matter, I don't care) and sends the value "null" instead (for privacy reasons). This causes app.mydomain.com to respond incorrectly (actual response varies based on implementation) and the login handshake fails.
I've tested both CORSMiddleware by starlette and the enable-cors annotation on the k8s nginx ingress, (understandably) neither supports the "null" origin: When using enable cors annotation the response says method not allowed (because nginx does not capture the preflight request and it is answered instead by the fastapi backend with 405 Method Not Allowed since the endpoint is "GET" only), and when using the CORS Middleware the response is 400 Bad Request (since it is not configured to support the "null" origin).
As I understand the "null" value is non-negotiable and so the only recourse for me is to accept "null" as an allowed origin which would cause app.mydomain.com to respond correctly and process the login response from login.mydomain.com.
Share Improve this question asked yesterday guydoguydo 211 silver badge3 bronze badges New contributor guydo is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct. 1- Show some actual code/configuration and the error message you get. – super Commented yesterday
1 Answer
Reset to default 0For anyone looking to implement this scheme, consecutive CORS redirects are simply not supported to protect the user's privacy.
The best mitigation I've found is to respond to the first redirect with a webpage that has a built in script which issues the second redirect. This allows chrome to fill the ORIGIN header correctly and allows either CORS Middleware or the enable-cors annotation to facilitate the preflight requests "one at a time".