Monday, 17 March 2008

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 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. would not allow third party developers to access services, but would. can use forms based authentication to log in users, but should not leverage this. 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 authentication (or whatever session based system). There is a potential that if I then browse onto 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 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).

1 comment:

Younes said...

Great post. Thanks.