There are perhaps still creative bypasses to this, but it should almost
entirely stop CSRF from happening by preventing the browser sending
session cookies on cross-origin requests to the API service. This
should, nevertheless, mitigate almost all CSRF.
I chose Strict because we will never send requests to the backend
directly off of links from other sites: the front end is the only thing
sending requests.
BREAKING CHANGE: if we have some other web site than the membership site
accessing the API, this would break it. I am not aware of one, but
please tell me if there is one.
I also set HttpOnly on the session cookie because there is no
conceivable reason that JavaScript could ever want to see it.
I didn't set Secure because, although it would stop a funny attack with evil wifi, it would also break local dev instances and I am going for easy mitigations right now. HSTS should stop that anyway.
There are perhaps still creative bypasses to this, but it should almost entirely stop CSRF from happening by preventing the browser sending session cookies on cross-origin requests to the API service. This should, nevertheless, mitigate almost all CSRF.
I chose Strict because we will never send requests to the backend directly off of links from other sites: the front end is the only thing sending requests.
BREAKING CHANGE: if we have some other web site than the membership site accessing the API, this would break it. I am not aware of one, but please tell me if there is one.
I also set HttpOnly on the session cookie because there is no conceivable reason that JavaScript could ever want to see it.
I didn't set Secure because, although it would stop a funny attack with evil wifi, it would also break local dev instances and I am going for easy mitigations right now. HSTS should stop that anyway.
These changes will apply on new sessions.
Tested locally and the site seems to work.
Docs: https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#define_where_cookies_are_sent