This project has moved and is read-only. For the latest updates, please go here.

SPServices Security Risk

Jun 22, 2011 at 5:01 AM

Hi Everyone,

I definitely love the no code solution power of SPServices but I am a bit lost on how I can responsibly introduce something like this into a SharePoint farm.  Wouldn't it be opening up my entire database to anybody?  Has anybody found a good way to lock it down ?  If I was trying to hack the farm and this was on a site collection somewhere I would go to whatever page is calling it and inject my own javascript onto a page that has it by just running MS developer tools and setting a breakpoint and then using run script from the MS developer tools console.  Am I missing something here?

- Concerned.

Jun 22, 2011 at 8:50 AM

SPServices doesn't open the farm much more than the SharePoint built in Web Services do out of the box. And certainly it does not open up the database at all. The framework only helps to more efficiently use them. Anyone javascript and XmlHTTPRequest aware can do the same without SPServices or jQuery for that matter. They can use a variety of tools from the Content Editor Web Part to Silverlight, PowerShell and WinForms/WPF applications.

Jun 22, 2011 at 1:13 PM

SPServices doesn't open ANYTHING up that the Web Services don't already allow. All calls are permission trimmed, just as user actions are in the UI. SPServices simply makes calls to the Web Services easier. There is no way to elevate permissions, and even if there were, I probably wouldn't want to build it into SPServices.

Just to reiterate, and calls you make to SharePoint's Web Services are done in the context of the cxurrent user, and there is no way to change that.



Jun 22, 2011 at 1:14 PM

@ACrush: +1 

Also note, if the user(s), do not have rights to the items, then they cannot manipulate them using Web Services.  This library is essentially a wrapper for the Web Services with some added sugar.  All of these Web Services are bound to the rules of SharePoint, just as if you were interacting with SharePoint directly.

If you are worried about end users manipulating your code, then you should obfuscate your code.  Also note, checking for permission levels of the user via Web Services and doing something with that information, isn't secure at all because of the same concerns you have above.

At the end of the day, SPServices is as secure as SharePoint is OOTB.

Jun 23, 2011 at 2:58 AM

Hey Guys,

Thanks so much for the responses.  I am pretty new to the SharePoint world but not to web app development so I am just finding my way around.  ACrush it seems that most end users wouldn't have the ability to drop in a Content Editor Web part, or add in Silverlight or deploy a winform/wpf app to be able to do this.  It seems its limited to content managers and up or at least someone above read only rights however that looks in the farm. 

Sympmarc I am glad to hear there is not a way to elevate permissions for SPServices.  It does help me to hear that the calls are made in the context of the user as well so they can't go peaking around a list or library they shouldn't be.

iOnline247 obfuscate wouldn't really stop someone very motivated in seeing my code, but would at least introduce a speed bump of sorts.

If I was going to use this code is it any more or less secure to stick this code in a content editor web part and then obfuscate as opposed to building out a user control/web part/visual web part?  I have something working where I used a content editor web part so that I could use SpServices to grab some information from a list I don't want users to be able to navigate to and then I am using some jquery to introduce a much more fluid filtering control for that information as opposed to what comes as ootb filter web parts in SharePoint 2010.

Thanks again for taking time to respond.

-Getting there

Jun 25, 2011 at 5:20 PM
Edited Jun 25, 2011 at 7:50 PM


The issues here are no different than using script in any other Web development situation. If you embed your business logic, it's "open" to your users. That said, I've rarely found a user who could decipher anything far enough to gain anything from it. Obfuscation (usually in the form of minification) is generally unnecessary, though minification can reduce the bandwidth requirements for downloading the script files the first time (caching!).

"Secure" is entirely a relative term. I would say, however, than if you are going to read values from a list you don't want users to have access to with script, I wouldn't call it "secure". You have to expose the fact that the list exists in your script, so those savvy users everyone worries about (unnecessarily in most cases) could glean that the lists exists. Your users would have to have read access on the list, so if they know what they are doing, they could navigate to, say, the AllItems view of the list.

You should define your security requirements and then see how this all stacks up. BTW, some of the same issues exist even if you use managed code. If the users need to have read access to a list and they figure out where it is...