re: CORS, In A Way I Can Understand VIEW POST

FULL DISCUSSION
 

Ok I have some questions since i have been struggling with this for ages now.

If Miss Patty comes over and someone knocks on the door can she let them in? Or is your daughter still the only one that can open the door?

Wouldn't it be easier to set what something can do instead of what they cant do. Your friend cant paint the walls doesn't mean that they cant paint the ceiling or for that matter the lap hanging on the wall.

CSP would be another great topic.

 

The pre-flight request (OPTIONS) is issued by the browser before the original request is sent to the server and will mostly match the intended request. For illustration, GET /books/1234 would look something like OPTIONS /books/1234. The server should be setting the pre-flight response appropriate to the resource on the server. So OPTIONS /wall?paint can return different allowed methods than OPTIONS /ceiling?paint. It is a responsibility of the server to enforce specific CORS policies.

I am of the personal opinion that CORS is currently pointless since browsers have to opt-in to implementing this control. It does a great job of being descriptive to the browser user-agent of the capabilities of the resource, but that description generally is hard to describe in any efficient way (assuming large sets of APIs).

If you are serving traffic from user-agents that are not a browser, than the API is essentially acting public anyway and the CORS control is no longer triggered. This is where it becomes important to authenticate the User Principal and authorize against identity claims as to what that user can do with that public resource. This is where OAuth and Open ID Connect play.

code of conduct - report abuse