This is a very basic article, as I haven't published any public articles in quite some time. This is a really simple theory. CORS is a lock added to recent browsers to stop badly written or malicious code from breaking servers, and to preserve IP rights. With older browsers, one may upload a comment to a popular news site; which has embedded JS, the JS is to request to view a resource on a fourth site repeatedly. A million people view their favourite news, incidentally view the comment. The fourth server is flooded with all the requests, and will have problems keeping up (i.e. DDOS, 1).
The CORS 2 3 process uses an OPTIONS HTTP 4 request first, to determine if an AJAX request may occur. Systems need to support the OPTIONS, this more of an issue for REST systems 5 which may require more work to add this. The OPTIONS response looks like a HEAD response 6. CORS headers are just more HTTP headers 7 8 9. The AJAX requests should announce what service they are calling from by using a Origin header 10.
In practice the OPTIONS request needs to be implemented fast and light. The above scenario would still leave the fourth party server processing millions of OPTIONS headers.
UPDATE, more recently browsers are constraining what headers one may set from JS. The browsers are implementing the following RFC 11. Things relating to cookies can be set via cookie 12. I normally use a wrapper object 13 to do all the date manipulation etc.
I started a section marked 'Protocol' to be more articulate, but after I put my references in, this seemed excessive. Many of the above links are RFCs.
From my perspective, (generally platform architect, developer and performance adjuster), CORS is another hygiene factor, like using correct line endings. It is trivial. It is done once at the start of the project, and isn't time consuming unlike making sites UI feel simple/easy from the users perspective.
To manage CORS practically, run your browser in a web dev mode that reports all errors (e.g. in Firefox, use firebug). Use all the features of your site. When there are CORS warnings, you have either got the headers wrong, or they are absent. There may be more specialised tools, but I haven't needed them yet. Assuming an average site, the time cost is getting all the third party services setup correctly.
If you need to test anything in detail (i.e. a range of Origin headers), I have been using cURL. It is trivial to integrate PHP module cURL into a PHPunit or similar tool to have the entire thing as a proper unit-test. Any fully configurable HTTP client would also work. When I talk about these, with external people I have been sending NetExport logs (a firebug extension/plugin 14), as its easier to show non-programming support-desk people than a unit-test.
Recipes for goal focussed people
To create the headers: