Why does it matter if CSRF or CORS is stateful or stateless? Is there really a need for manual intervention here?

If your API is stateless, which to me implies no "session" cookie or other auto-keep-logged-in mechanism, you aren't at risk of CSRF, because requests made on a users behalf from another site won't have them logged in.

Suzzer specifically said he had problems getting CSRF to work with a stateless API, so I find that confusing.

Oh sorry. We have an exposure layer that they really wanted to be completely stateless, but there is still authentication going on and the exposure layer proxies to services behind it that could have user sessions. So they only thing they had to push to a stateful layer was CSRF. That's about all I know. I am not a CSRF expert.

I find the interchsnging of CSRF and CORS unsettling.

They're completely different things. CORS headers (and OPTIONS response) are required by the browser for certain cross-domain calls. CSRF is a kind of attack.

This is not true. Any form taking POST params is open to CSRF. The CSRF token is basically a hidden <input> field. By default, CSRF tokens last for the individual form submission, and has to be reset before a form submit can be handled again.

It doesn't matter if the user is logged in or not. As long as a form can be submitted, the CSRF token is need to prevent CSRF attacks.

If, in effect, he is just trying to handle a POST param, then yes, it's arguably stateless. It sounds like his team is attempting to preserve the CSRF token for the next form submission, which is kind of strange and certainly an open attack vector. I have no clue why anyone would think preserving a token is a good idea, and certainly falls under rolling your own security, very poorly at that.

POST params....? i don't think i've ever made a POST with params...don't you just include everything in body as json?

are you writing native html in 2017?

JSON is the Bride of XML, yet somehow more horrific and ugly.

JSON is not worse than XML, you take that back.

Ok yes, I don't get how CSRF is a part of your app if it's an exploit.

I think people are generally talking about the tokens you use to protect yourself from CSRF attacks.

When I say CSRF I mean CSRF protection.

If by "attack" you mean "someone can post to my site" then, OK, fine, but that's not generally considered an attack. What csrf protection *protects* you from is someone posting a form that (accidentally) has additional state attached to it (namely, a session or something else). If there's no state, then there's no trick. I don't *need* to trick someone in clicking my POST button if I can click it myself just the same.

I almost hate to ask, but what do you favor?

In terms of protecting from CSRF attacks, the token doesn't need to be reset for each request. You can imagine a case like you have a page that can make multiple ajax requests that change state but don't reload the page. You can reuse the same token for requests made on that page because its still doing its job of ensuring that the request is coming from a page you sent the client (and not a malicious page thats just tricking the user into making the post request).

There are other attacks that you need to protect against (like replay attacks / man in the middle / those types of things), but you need to handle those differently than the CSRF token anyway.

JSON is more horrific and ugly than XML...

The things I read in this thread...

XML for applications of scale, JSON for web development. But nothing beats binary stored to disk.

Why are we using XML for applications of scale?

Probably to take advantage of it's slowness, inflexibility, requirement of buggy libraries for parsing and searching, and so forth?

XML can die in a grease fire.

Yeah, I don't think we use it anywhere and I don't really know of a use case where its the best option. But like I said, I'm not up-to-date on a lot of things.

I'm using it to save and transmit data from spread sheets, but I haven't figured out yet how to make it flat binary data.

Boost has a cool ptree library which works with XML, so potentially game trees. I am not sure how to take advantage of ptree w JSON.

But in hindsight I am still clueless. I do,t know what's good for large scale applications.

http://www.boost.org/doc/libs/1_55_0...e/parsers.html

Doc claims XML is an "industry standard", but I have very little experience outside the bubble.

Add: json can be used w ptrees. I even touched on it and forgot.

Thanks all for setting me straight on XML.

As someone who's had to work extensively with XML and JSON - **** XML. I can't imagine one scenario where I'd prefer it.

Also without XML there would be no SOAP - one of the most cumbersome horrible technologies ever.

SOAP would have been pretty great if it actually worked, but mostly it did not actually work.

And when it did work, a lot of the time it was auto-generated from stuff like, I dunno, Java API classes, and it was an unholy mess. I spent a few of the worst years of my life integrating with NetSuite via SOAP.

We had a client who said they would provide us REST apis, and they last minute gave us SOAP apis and said it was basically the same thing so the problem was us.