SharePoint REST (ODATA) is Insecure

SharePoint 2010 includes a number of new services to allow interoperability with other systems and to make it easy to create rich Internet applications. Among these is SharePoint’s ODATA implementation provided by the ListData.svc service. Overall, I think the REST is an awesome lightweight alternative to formal SOAP. Unfortunately, the implementation SharePoint provides opens a large attack surface that makes it very easy to discover the information for every user in a site.

Unlike alternative interoperability services like the traditional SOAP based services and the SharePoint Client Object Model, you must access the ListData.svc with an account that has Browse User Information permission. Consider a scenario where you want to allow a system external to your organization to read and write items in a site. You can create a permission level that allows this interaction by granting:

  • Add Items
  • Edit Items
  • Delete Items
  • View Items
  • Use Remote Interfaces
  • Open

An account with this set of permissions allows the use of the Client Object Model and some of the SOAP services to the external system to read and write list items and documents. However, the account can’t browse the site’s contents because it hasn’t got View Pages permission, nor can the account access information about the other accounts with access to the site.

SharePoint’s WCF Services implementation, ListData.svc, will not work with the above set of permissions. To make it work, you must grant Browse User Information permission.

There are probably many scenarios where you can justify this, but I personally think that a data interchange technology that reveals the accounts with access to the data store is best avoided considering that the alternatives don’t have this flaw.

I hope this is fixed soon, because I’d love to use REST with SharePoint and I will as soon as Microsoft makes it possible to harden SharePoint REST (OData) security. At the moment I think it would be irresponsible to do so in most of the scenarios where REST is attractive.

Author: Doug Ware