Since XSRF validation involves matching of cookie/token sent in the UI request with the request header as part of that same request, what are the options for testing locally? So assuming I run my UI locally and I am pointed to server hosted in a different place, the cookie would never be able to read on localhost (since it is a different host). What is the best-practice in this case - is it adding logic on server to identify the Origin and bypassing the check if Origin is localhost ?
Asked
Active
Viewed 499 times
2
-
Use a reverse proxy, perhaps. So “localhost” doesn’t actually look like “localhost” to the browser when it makes requests. – user2864740 Jan 20 '22 at 07:03
-
Oh k...any reference...i am on react for ui..not sure if that is UI implementation or server-side? – copenndthagen Jan 20 '22 at 07:07
-
We use an in-house setup, so not immediately.. However the idea is that this proxy service can split requests to a local UI front-end layer as well as to the backend (which may or may not be on the same machine) using the same-to-browser host with a “full domain name” (localhost entries can do wonders). To the browser, all requests appear to hit the same “remote” server. There are probably easy-ish ways to do this with node.js. – user2864740 Jan 20 '22 at 07:10
-
(Err, that should be “*hostfile* entries can do wonders”.) – user2864740 Jan 20 '22 at 07:17
1 Answers
0
What I usually do in such a case is to use /etc/hosts and use a subdomain for my code running locally. E.g. the UI is run on www.example.com and the server is on api.example.com, then in my hosts file I point www.example.com to localhost.
If the cookies are not samesite cookies and the server has proper CORS settings, then in fact it shouldn't be a problem using them from localhost. Your UI won't have access to them, but the browser should send them together with any request to the server. (CORS should allow credentials and the http client of your UI should use something like a withCredentials: true flag)
Michal Trojanowski
- 10,641
- 2
- 22
- 41