Please see my comment to the question.
I got an impression that you have a big confusion, and, in particular, you don't know yourself what cross-domain activity you want to have. Please forgive me if I'm wrong about it, because of some kind of misunderstanding of your question, but than you will have to clarify it.
In all cases, I think you need to get clearer understanding of things. You can learn about
same-origin policy, CORS and Web security model in general:
https://en.wikipedia.org/wiki/Same-origin_policy[
^],
https://en.wikipedia.org/wiki/Cross-origin_resource_sharing#How_CORS_works[
^].
Here, I can only speculate on what you want to achieve, but let's make some initial logical steps. You can read that
This policy prevents a malicious script on one page from obtaining access to sensitive data on another web page through that page's Document Object Model.
Where are those "scripts" and "pages"? Maybe, there is no such thing. But even if you want to have something like that, what "cross-domain" may possibly mean? It may mean that some client sends some request to your custom WCF service. Part of this request could be some URI pointing to some Internet resource placed outside of the domain of your service; and the request implies that your service should deliver this resource on behalf of your client. Even if it is so, how your service, being custom, can be restricted from doing that? In relation to the foreign-domain service, your service is no different from any other client. You can retrieve any accessible resource based on one of the standard protocols using the class
System.Net.WebRequest
(a concrete class will be determined by the URI, please see
WebRequest.Create
static methods). That's all.
If you want to reproduce all the Web-specific security policies and then follow the standards related to CORS, you can do it, but it's hard to imagine the reason why would you do it. If I'm missing something, please explain it.
—SA