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

Atlanta based entrepreneur, author of many SharePoint books and videos, leader of Atlanta .NET user group, founder of InstantQuick, and SharePoint MVP.


  • Mohamed Saleh - Microsoft SharePoint Server MVP

    August 26, 2010, 4:38 am

    Hello Doug,
    The information in this post is not correct, usually any HTTP request with the WCF service of any list is established based on the security context of the loggedin user.


  • Doug

    August 26, 2010, 10:00 am

    I think you missed the point entirely! Of course the request is based on the security context of the loggedin user. The problem is that the security context must allow Browse User Information permission.

    I am not saying it is insecure because it grants access to list items the user shouldn’t see. It’s insecure because it exposes a tremendous attack surface by revealing the information for every account on the site including the site collection administrators. An attacker still needs to brute force or socially engineer the password, but the service exposes half of the required information an attacker needs to break into the site.

    If the server is connected to a domain it exposes enough information that the attacker can then use the account information to try to penetrate any publicly exposed sites or services over the internet including the ones that are other than SharePoint!

  • StacyDraper

    October 31, 2010, 8:01 am

    This is valuable information. I’m going to use odata just for my apps and make everyone ‘outsiders’ use soap. Or maybe if they own all the permissions. I think half the battle to a socially engendered attack is knowing who has access to what. What’s more is you can almost predicted the relationships. These kinds of attacks are the most detremental because they most often acheive their goals without detection.

    Thank you for bringing this into the world, I’ve been very excited about odata. Still am really but have something g to be aware of that I didn’t have to learn on my own. It’s a redicukous flaw that I would have never guessed. Thank you.

  • Mohamed Saleh

    November 6, 2010, 3:40 pm

    Hello Again,
    You are right, i didn’t notice your point…
    I will check it out to see how to work around this issue!

  • Mohamed Saleh

    November 6, 2010, 3:40 pm

    Hello Again,
    You are right, i didn’t notice your point…
    I will check it out to see how to work around this issue!

  • ali robertson

    April 12, 2011, 6:08 am

    isn’t it best practice to put all AD references in SP groups anyway?

    E.g. rather than granting access for domainusergroup, i set up an SP group called ‘My Users’ and put in domainusergroup, then I give access to sp group ‘my users’.

    If you’ve done this, then am I right in thinking that the information that is ‘browsable’ is just the name of the sharepoint group?

    Not saying this isn’t a massive problem – just wondering if this is a potential workaround…

  • Ali Robertson

    April 12, 2011, 6:12 am

    Further to my previous point, these are access level permissions in 2010. Note how all levels have ‘browse user information’. It seems it’s not possible to provide access to content without providing this information anyway?

    Ali Robertson –

  • Doug

    April 20, 2011, 8:28 am

    Hi Ali,

    Great comments!

    The default associated goups on a team site are indeed associated with permission levels that contain this permission. It makes sense that they do because they are for sites to facilitate collaboration between users.

    However, it is not required for access. Consider the Restricted Read permission level found on a Publishing Portal. It has Open, View Items, Open Items, and View Pages only. In other words, you can read a page that has author information (Created By, Modified By), but you can’t traverse those fields to the User Information list.

    I stand by my opinion… If the purpose of the REST interface is to provide lightweight integration between systems for access to information in SharePoint then it provides a big attack vector in its current form. The other service APIs do not have this same flaw.

Comments are closed