How to make client application secure in sharepoint

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.