Cross Domain Security Practices

There seems to be a little confusion regarding cross domain security, not only in the Silverlight world but in the flash world also. The confusion seems to be mainly regard about security risks.

There are 2 real scenarious regarding api's:

1) Exposing a service to your own applications
2) Exposing a service for consumption to third party developers (e.g. Mashups).

Exposing to your own applications
I will be doing a post on this later this week. However if you are writing a service to expose to your own silverlight applications, then you should not open up your application to third parties. Therefore in your clientaccesspolicy.xml or crossdomain.xml you should ensure that you do not allow third parties to access your site. If you wish to restrict services to logged in users of your site, you can use asp.net compatibility mode with a WCF service to provide this level of protection (I will blog about this later this week).

Exposing to third party applications
This is a very key point, if you wish to allow Silverlight or Flash third party developers access to your service (via clientaccesspolicy.xml or crossdomain.xml), you must seperate the service from your existing authentication system. Rather than using a session based authentication system, you must use a message based authentication system.

The best thing to do is use a different subdomain for your service / api from the mainwebsite, and only open up third party sites in subdomain. i.e. www.chrishay.com would not allow third party developers to access services, but api.chrishay.com would. www.chrishay.com can use forms based authentication to log in users, but api.chrishay.com should not leverage this. api.chrishay.com should use a message based system (e.g. providing a token,username/password as part of the message)

The reason we have to be very careful about this is the following:

If I exposed my services (lets say bank account service) to third party developers via my crossdomain.xml (or clientaccesspolicy.xml), and allowed my API to authenticate using asp.net authentication (or whatever session based system). There is a potential that if I then browse onto MrNastySite.com it would be able to make a crossdomain call to my site, leverage my already authenticated user and start extracting private information (as it would already be considerd as logged in). By implementing a message based system, with a seperate domain (with seperate policy files), with a seperate authentication system, there is no way for mrnastysite.com of hooking into my previous session and stealing my data.

So the golden rule is this when exposing services to third party developers.

1) Expose your API services on a different domain from your main website
2) Restrict your main website domain to your own applications only
3) Maintain a seperate clientaccesspolicy.xml (or crossdomain.xml) for your API domain
4) Use a message based authentication system for your third party api (if you need to implement authentication), do not use a session based system (cookies etc)

Anyway I hope this helps clear up some confusion. It is not only small companies that have experienced this confusion. Only up until about a week ago, did Twitter have their main website open to third party developers (they have now restricted this policy).