1

For example, if an app uses the JSforce framework to develop a page that uses AngularJS, could it be blocked because of this? I'm wondering because some parts of the code would have queries and other code that manipulates the data on the page, and it would store some records while the user is using it. Could this be flagged as a security issue?

I'm almost sure it does not, because we are using Salesforce's endpoints for manipulating data, instead of a custom Apex endpoint, and the user needs to be logged in to access the page and (probably) use the endpoints.

Improve this question
  • Just to be clear here, sounds you're developing an AppExchange package that uses the Metadata API? – Sebastian Kessel Dec 7 '16 at 16:20
  • Maybe one or two calls to the Metadata to describe a field (to populate picklist values on a page that is generated with JavaScript). – Renato Oliveira Dec 7 '16 at 16:24
  • 2
    I am wondering why you need to hit the REST API to get data from Salesforce (or picklist describes). You can do all of that, from Angular, by calling standard @RemoteActions against a VF controller. – Sebastian Kessel Dec 7 '16 at 18:16
  • It would also save the client installing your package from a number of API calls, which are not unlimited. – Sebastian Kessel Dec 7 '16 at 18:16
  • 2
    I can't comment on your architecture, really, but the same gov limits apply on REST calls as they do with Apex. I advise you to reach out to your SFDC SecRev contact (or book time in their office hours) and present them with your scenario and have them weigh in, I suspect they won't like your approach but I also suspect they won't stop you from using it. – Sebastian Kessel Dec 7 '16 at 18:23
2

Many Apps on The Appexchange use the REST/SOAP API, and have no issues with the security review. We have the following requirements:

  1. Use an OAuth Token. Don't steal the user's session Id and authenticate with it. Get explicit authorization via OAuth before making API calls on behalf of the logged in user. We really need to avoid a situation in which, say, a stock quote app, just because it is used by an Admin, will start installing packages or adding users. So the permission of what your app can do is not the set of things that whoever is using your app is allowed to do. Apps are supposed to have limited scope, and you need to ask for authorization from the user. Once you get authorization in the form of an OAuth token, then use that token to make calls on behalf of the logged in user.

  2. If storing the creds (Oauth tokens) in a third party service, make sure they are encrypted with AES-128 or greater and that the key to decrypt the creds is not accessible to the DB layer but is only accessible to the App layer. Use vendor provided libraries to do this, rather than rolling your own encryption/key storage functionality.

  3. It's OK to use the metadata api or tooling API to modify metadata, but not to modify code of your own package. E.g. we don't want self-modifying code or to override the package publishing system, but if your app is an IDE or has some other reason to load classes, then that's fine.

Improve this answer
  • This part of using an OAuth token is the kind of thing I needed to know. At the moment we use the user's session Id to authenticate and call the API. We will need to change that I guess. – Renato Oliveira Dec 9 '16 at 1:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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