>It is protected by if the request uses JSON or similar.
Only if the server checks that the Content-Type header is JSON. If the server ignores the Content-Type header and simply decodes it as JSON, it's not protected. I think there are probably a lot of servers that simply decode the body as JSON without first checking the Content-Type header and thus the same origin policy doesn't protect them from CSRF.
>The point is still that this is the target problem that it is trying to address.
It doesn't seem that way to me. The same origin policy successfully prevents one website from reading the content of another website. It's fully addressed. It seems to me that's the primary problem it's trying to address. The problem of one website sending requests to another website is only partially addressed, so it seems to me that's considered a secondary problem.
>I think demonstrating how full of holes the default policy is is a great way to emphasis that you should not rely on the default protections.
The default policy is full of holes for sending requests, but not for reading the response. I agree you shouldn't rely on the default protections for sending requests, and should implement your own CSRF protection for all state-changing handlers. But I think it's fine to rely on the default protection for reading responses, and thus I don't think it's necessary to recommend CSRF protection for non-state-changing handlers.
The reason I always first describe the same origin policy and CORS in terms of reading responses is that I think it leads to less confusion. If I first explain about sending requests, I have to explain that it doesn't really work, and people thus are confused about what the purpose of the same origin policy and CORS is if it doesn't even protect against the thing it was designed to protect against. Either that or they mistakenly think it does protect against sending requests, and implement sites with CSRF vulnerabilities erroneously thinking the same origin policy and CORS will protect them. By explaining first about reading responses, people quickly understand that. I then explain that it doesn't protect against sending requests, and thus state-changing handlers need CSRF protection to be implemented.
>CORS and the same origin policy are the same thing, two sides of the same coin. They express what is allow and what isn't. CORS is a configuration layer for the same origin policy, allowing you to change the default policy.
I guess I can see that, but the names of them don't really lend themselves to that understanding. The same origin policy is about same origins. If it starts allowing cross-origin communication, then it's no longer living up to its name. So I see that as it being disabled. Similarly CORS is about cross-origin sharing. If it starts blocking things, then it's not doing sharing, and thus not living up to its name.
According to Wikipedia the history backs up my understanding. It says the same origin policy was created in 1995, and CORS came later, first proposed in 2004.
https://en.wikipedia.org/wiki/Same-origin_policy
https://en.wikipedia.org/wiki/Cross-origin_resource_sharing