CSRF, CORS, and HTTP Security Headers Demystified
blog.vnaik.com
CSRF, CORS, and HTTP Security Headers Demystified
1–10 of 44 posts
Re: CSRF, CORS, and HTTP Security Headers Demystified
#2Trying to demystify CORS in a couple of paragraphs....good luck with that! I think 200 page book would still be too short to demystify it. It's a crazy topic
Re: CSRF, CORS, and HTTP Security Headers Demystified
#3This is good information, and I'd love to see a write up how Firefox, Chrome, Brave and other browsers can be set up to prevent some of this.
For example, Firefox has both first-party isolation mode and now Total Cookie Protection, which isolates cookies and would thus likely prevent CSRF. However, I think first-party isolation causes CORS issues like when trying to pay with Paypal on another retail site.
Re: CSRF, CORS, and HTTP Security Headers Demystified
#4Trying to demystify CORS in a couple of paragraphs....good luck with that! I think 200 page book would still be too short to demystify it. It's a crazy topic
I never understood the difficulty with CORS. It's dirt simple: don't send requests across domain names. And if you do, make sure you return header(s) from the target resource to specifically allow the origin to request it.
All the difficulty seems to be people trying to do crazy, esoteric things there's no good reason to be doing in the first place.
Re: CSRF, CORS, and HTTP Security Headers Demystified
#5This is good information, and I'd love to see a write up how Firefox, Chrome, Brave and other browsers can be set up to prevent some of this. For example, Firefox has both first-party isolation mode and now Total Cookie Protection, which isolates cookies and would thus likely prevent CSRF. However, I think first-party isolation causes CORS issues like when trying to pay with Paypal on another retail site.
> However, I think first-party isolation causes CORS issues like when trying to pay with Paypal on another retail site.
Generate URLs with a time limited token as query param. No cookies needed.
Re: CSRF, CORS, and HTTP Security Headers Demystified
#6> It is good practice to always use the SameSite directive with cookies as this provides protection against CSRF attacks.
Be careful with assuming SameSite fully protects from CSRF attacks. I thought it does, but then I read what "site" actually refers to in the context of same site (eTLD+1).
If the eTLD+1 (i.e. company.com) is not listed on the Public Suffix List, even SameSite=strict cookies for a.company.com will still be sent for requests initiated from b.company.com
Re: CSRF, CORS, and HTTP Security Headers Demystified
#7Trying to demystify CORS in a couple of paragraphs....good luck with that! I think 200 page book would still be too short to demystify it. It's a crazy topic
I never understood the difficulty with CORS. It's dirt simple: don't send requests across domain names. And if you do, make sure you return header(s) from the target resource to specifically allow the origin to request it. All the difficulty seems to be people trying to do crazy, esoteric things there's no good reason to be doing in the first place.
I wouldn't call trying to write a web app that aggregates across multiple services on the client-side doing something crazy.
Re: CSRF, CORS, and HTTP Security Headers Demystified
#8Trying to demystify CORS in a couple of paragraphs....good luck with that! I think 200 page book would still be too short to demystify it. It's a crazy topic
I never understood the difficulty with CORS. It's dirt simple: don't send requests across domain names. And if you do, make sure you return header(s) from the target resource to specifically allow the origin to request it. All the difficulty seems to be people trying to do crazy, esoteric things there's no good reason to be doing in the first place.
There's a lot of arcana that you're skipping over. It's easy to get CORS partially working on your development machine only to watch it fail in production or only fail on certain browsers or certain ports. There's silly things that need to happen if your application receives traffic from multiple domains. Our CORS middleware is ~100 LOC.
Re: CSRF, CORS, and HTTP Security Headers Demystified
#9Earlier quoted context omitted.
I never understood the difficulty with CORS. It's dirt simple: don't send requests across domain names. And if you do, make sure you return header(s) from the target resource to specifically allow the origin to request it. All the difficulty seems to be people trying to do crazy, esoteric things there's no good reason to be doing in the first place.
There's a lot of arcana that you're skipping over. It's easy to get CORS partially working on your development machine only to watch it fail in production or only fail on certain browsers or certain ports. There's silly things that need to happen if your application receives traffic from multiple domains. Our CORS middleware is ~100 LOC.
> Our CORS middleware is ~100 LOC
What?! For responding to OPTIONS requests and setting the right header on responses from your backend?
I don't really see the problems you're citing to be a cause of "complexity in CORS" either, but more not having a proper development setup or similar. CORS is specifically about domains. As long as you set the frontend domain as accepted origin in your responses from the backend (and respond to OPTIONS), you're good to go.
Re: CSRF, CORS, and HTTP Security Headers Demystified
#10Earlier quoted context omitted.
I never understood the difficulty with CORS. It's dirt simple: don't send requests across domain names. And if you do, make sure you return header(s) from the target resource to specifically allow the origin to request it. All the difficulty seems to be people trying to do crazy, esoteric things there's no good reason to be doing in the first place.
I wouldn't call trying to write a web app that aggregates across multiple services on the client-side doing something crazy.
But what does that have to do with CORS? If you're just writing the client-side code (what runs in the browser), then you have no control over 3rd party origins, hence either you can use their API or not. Unless you write your own backend also, and then supporting CORS is trivial.