In the "Allowing multiple origins" example, Vary: Origin should be set in the response to avoid incorrect content being served (if content may differ depending on the requesting origin). See fetch.spec.whatwg.org/#cors-protoc...
Good point, thanks for your input! Added it to the example in that section :)
Do we need CSRF protection if CORS is disabled (now allowed from other domains) ?
For me it seems logic that is no need for CSRF protection if CORS is disabled, but couldn't find any exact answer.
Note that without CORS headers the request is still happening, you just don't have access to the response. Unless you have some server-side mechanism to detect requests from other origins, you could still run the risk of CSRF. I'm with @theincorrigible1
that you should protect against CSRF on any inputs that can change state.
Here's a potential example:
Now I get it.
But can the attacker make a simple request, and get a CSRF token,
then make second request with that token included?
You should protect against CSRF on any inputs that can change state imo.
Cross-site request forgery
Cross-origin resource sharing
If no one from another origin is able to make requests to your site (CORS disabled),
then CSRF is redundant imo.
But that's not what CORS does. Re-read the warning in the article.
Thanks for writing this. Bookmarked.
I'll just leave this here :)
@TheJSDev @g33konaut that's a week #CORS intro. If you are looking for something more hands-on, see this @observablehq #talk thread & @glitch #proxy I put out for 'em last year 😁. Go #fetch! ...talk.observablehq.com/t/any-plans-fo…cc @ThePracticalDev
11:58 AM - 16 Nov 2019
I'm confused. It sounds like you're insulting the article (looks like you're calling it "weak" but typo'd), but offering no real alternatives to anything posted here.
I followed your link but it just seems to go to a random forum post where you discuss cors-anywhere, not educating anyone on CORS itself.
If you have some constructive criticism or something to add value to this post, feel free. This just reads like you're being aggressive and not helpful.
I for one found the OP educational and helped me understand things better.
my follow up is here:
You should really just follow the links ...
I hope you'll find it handy and educational too ;)
You just link to a basic example that uses CORS at some point, then a link to the MDN docs on CORS. If by educational, you mean I get to read that, then I guess?
I far prefer OP's article here, since it walks through why the various CORS headers are needed, and the results of each stage.
No need to be a jerk about it.
haha! how about your write your own post on #CORS rather than keep on piling up here ...
I provided context for CORS in action on one of the frequently used online sites for devs & data scientists, with a brief example any dev can try on Observable HQ || glitch.
If you'd rather read long CORS specs recaps & clone a github repo with that simple nodeJS index.js example, I'll leave it up to you.
I don't get why you think you're being "piled up on". You started by insulting the article on Twitter, then linking that tweet here, effectively insulting it again.
You aren't the victim, you're being called out for being a jerk.
My advice is to look closely at what you did, apologize and do better going forward.
Kevin, go write your ideal post on CORS. You could use 1 :)
I don't think that there is any need to be rude. I thought that it was a pretty helpful article. You could add supplementary content in the comments without being a jerk 😒
agreed! & I posted as such here: dev.to/tarasnovak/comment/i0jh
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.