Considering sharepoint development is mostly moving to client side with JSOM, REST api exposed. Even in recent announcement we have Sharepoint framework based on Client side.

With this I am assuming MS really want us developers to develop solution based on Client technology.

I had one question considering above. For any application developed with JavaScript etc, the application runs under the context of current user.

So i want my client application to create/edit items in list through front-end,so i Must provide contribute access to all the users. However, if this is little confidential, e.g Leave rquests, reimbursment reqeusts, I still have to provide users contribute access.

If few of my end users have Sharepoint knowledge, they can very much write javascript code and run that in browser developer console and can add tens of thousands of records to the list in few mins.

For a moment thought may be we can have app only policy and control this with permissions, but again sharepoint-hosted apps do not support app only policy.

I would like to know, what is the best way to handle such scenarios i.e. to have complete client based solution and handle the security as well? I understand we can write have server side code etc the old traditional way with run with elevated prev., but m really interested in client based applications.

3 Answers 3


So you are correct, in that js code is running in the context of the current user, and can effectively make calls to SharePoint as that user. I touched on this a bit in the 'Why SPFx' page here - https://github.com/SharePoint/sp-dev-docs/wiki/Why-SPFx

There is a feature called 'NoScript' (or depending on your depth of knowledge, the removal of ACP permissions - add/Customize Page) that is applied to most self-service created sites in O365. What that states is that a user - even if they are an admin of a site - can't inject js onto a page via the normal methods (script editor webpart, jslink, custom actions). In order to inject script, the tenant admin needs to give you a site with noscript disabled.

Now for the framework, in order to activate the webpart on a site collection, the tenant admin (or their delegate) needs to approve the webpart for general use, and gives the admin a single place to disable the part if it is causing issues.

  • however, even if scripting is disabled, they are still free to use browser developer tool on sharepoint page, where they get current context and can run any piece of code, right? (provided they have that access, contribute etc.)
    – Rohit
    Commented Aug 23, 2016 at 5:50
  • 1
    Yes, but I'm not sure how that relates. I imagine it would be easier for them to just use the normal web UI to make those changes. Commented Aug 24, 2016 at 5:20

There's no way you can elevate permissions and similar using client side techniques. If you really want that you need to use client side code to call into "something" server side that does that for you.

Of course you can set permissions on lists, so that you only are allowed to read, read/write or manage the list items. All client side techniques respect the list permissions.

Also, one thing that far to many forget about is the Item-level Permissions where you can specify that users only can see or update their own stuff.

  • Thanks Wictor, but I am not concerned about view (GET data) but about create/edit (POST data). If its browser client application, where i want my user to add list item through fancy HTML form, i must give them at least "Add Item" custom permission. I dnt think item-level permission can help. With Add item access ayone can add items through any way not jsut my fancy HTML form. Also for item level permission you have to keep monitoring the list if there is new item added, which u dono when user is going to add.
    – Rohit
    Commented Aug 21, 2016 at 14:39
  • With client side code, it is the permissions they have on the list that matters. So if they can write, they can write, and also write any item in that list. There's no way around that, expect using an external API, as I explain OR by using item-level permissions where you only allow the user to edit their own items. Commented Aug 21, 2016 at 14:42
  • Hmm okay. I really wish MS adds some mechanism here if they are promoting client side development so much. May be some business rules which can act as secret key , so only items with proper key can be added (just wild idea)Thank you anyways Wictor.
    – Rohit
    Commented Aug 21, 2016 at 14:46
  • 1
    It's not as easy as one may think. If you have that "secret" or whatever - any script can use that one and that would be like open a can of worms. We will see malicious code in scripts in no time. Commented Aug 21, 2016 at 14:48
  • 1
    I understand, for a moment i thought may be i can use Column validation and put validation such as only I know how to PASS , but again I have to pass that validation through fancy HTML form with javascript which any developer can find by browser debugging. I guess ultimately i have to use server side code to have "Secure" application and just client side development is not sufficient :(
    – Rohit
    Commented Aug 21, 2016 at 14:53

I think your assumption "With this I am assuming MS really want us developers to develop solution based on Client technology" is incorrect. Without being able to read their minds, it would be fair to say that Microsoft engineers in general want us to move our development away from full-trust code running within SharePoint (and mentioning that this continues to be supported on-premises). The reasons are mainly to support Office 365, but also because full-trust code is a support headache and a frequent upgrade blocker.

But it doesn't have to be client-side technology in the sense of running in a browser or an "app" as it could well be server-side which includes a large number of technologies, including ASP.NET MVC, PHP, NodeJS, etc. etc.

One of the problems with client-side technology is that it is impossible to completely protect the code from tampering and inspection, so there will be many use-cases where server technology is required, or just easier to implement.

Apart from the move away from full-trust, it really isn't Microsoft's job to tell you what technology to use. Their job is to provide you with options, so think of the SharePoint Framework as another option for client-side development. Neither SharePoint Framework alone, nor any of the purely client-side approaches is a great fit for the requirements you describe - you are probably going to need to implement this as a partly or wholly server-side solution.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.