[lyu07282]

Exactly you can also trigger forms for POST or DELETE etc. this is called CSRF if the endpoint doesn't validate some token in the request. CORS only protects against unauthorized xhr requests. All decades old OWASP basics really.

[formerly_proven]

That highly ranked comments on HN (an audience with way above average-engineer interest in software and security) get this wrong kinda explains why these things keep being an issue.

[mrguyorama]

I'm betting HN is vastly more normal people and manager types than people want to admit.

None of us had to pass a security test to post here. There's no filter. That makes it pretty likely that HN's community is exactly as shitty as the rest of the internet's.

People need to stop treating this community like some club of enlightened elites. It's hilariously sad and self-congratulatory.

[lyu07282]

I don't know why you are getting downvoted, you do have a point. Some of the comments appear knowing what CORS headers are, but neither their purpose nor how it relates to CSRF it seems, which is worrying. It's not meant as disparaging. My university thought a course on OWASP thankfully, otherwise I'll probably also be oblivious.

[_cenw]

If you're going cross-domain with XHR, I'd hope you're mostly sending json request bodies and not forms.

Though to be fair, a lot of web frameworks have methods to bind named inputs that allow either.

[bawolff]

This misses the point a bit. CSRF usually applies to people who want only same domain requests and dont realize that cross domain is an option for the attacker.

In the modern web its much less of an issue due to samesite cookies being default .

[bawolff]

> Exactly you can also trigger forms for POST or DELETE etc

You cant do a DELETE from a form. You have to use ajax. If cross DELETE needs preflight.

To nitpick, CSRF is not the ability to use forms per se, but relying solely on the existence of a cookie to authorize actions with side effects.