I am finding it pretty exciting to make webservice calls directly from visualforce + javascript. Specially with frameworks like Angular, you can directly consume JSON and render HTML templates pretty quickly. As this saves 1 extra hop to reach Salesforce servers via Remoting and then calling actual API endpoint.

Only down side to this approach is Salesforce security, which is completely bypassed, i.e.

  1. No need of any remote site settings etc.
  2. All calls are made from Javascript, so API Keys might be hacked. In some cases its not that critical, specially when getting geo locations etc via Google maps.

What are your thoughts on this approach ? This would surely not get thru Security review, if I am not wrong ?

  • 1
    Doesn't this still consume API requests? That's a big downside if that's still the case. – Kevin O'Hara Jul 24 '14 at 16:56
  • If we have a system and we are doing Oauth its still good I guess during security review but not sure otherwise – Mohith Shrivastava Jul 24 '14 at 17:01
  • How do you avoid xss issues when doing a javascript call directly to the endpoint? – Daniel Hoechst Jul 24 '14 at 17:10
  • @KevinO'Hara no it bypasses sfdc completely, so no API requests consumed. – Abhinav Gupta Jul 24 '14 at 17:23
  • @MohithShrivastava we are getting api keys to various Google services, so not really oauth here. – Abhinav Gupta Jul 24 '14 at 17:24


I would look at this based on the correct placement of logic (aka separation of concerns) calling the desired API in conjunction with an optimisation perspective. In the case of logic consuming Google Places and Geo API's typical scenarios are JavaScript client side based, hence why Google provide JavaScript client side libraries.

Browser restrictions on making API calls client side...

There is also the fact that its not possible to make web API calls from JavaScript to a domain outside of the domain your page is served from, see Same orgin policy. If however your chosen API offers this ability through JSONP or the more favourable CORS standard to permit calls to be made cross origin you can of course choose server or client side.

Thoughts on remotetk...

Note that the proxy approach used by remotetk, essentially makes the call via Apex code on the server on the clients behalf, will still require Remote Site Settings to be setup, as such I would not expect the Security Review team to necessarily fail in respect to this, though they may raise concerns about bypassing CRUD and FLS security, as i don't see any checks for this in the code here. That said, ultimatly the Salesforce REST API the proxy delegates to will be enforcing this, so i suspect this might be something that can be explained to the Security Review team.

More of a logic placement thought...

Basically ask yourself if the logic belongs on the client or is better served from the server. Then if the user would really would benefit from skipping a server side step or not. Rich clients are becoming increasingly popular and as a result Apex controller logic in such solutions is minimal in some cases. That said if your looking for transactional containment around any database updates your making following API callouts, then your still going to want to wrap this in server side code, leveraging something like JavaScript Remoting. Finally before you get to carried away writing JavaScript code, do make sure you have a good unit testing framework in place.

Security and Sensitive Info

From a security perspective, I think you have mainly answered your own question in respect to expose some potentially sensitive credentials / tokens in respect to your use of such API's from JavaScript code.

Package Installation

My last thought would be more in respect to advertising what third party services you are using during package install. Since when you define Remote Sites adminstrators can see where data is flowing outside of Saleforce easily. Something may want to consider documenting clearly in your release notes if some callouts made client side.

| improve this answer | |
  • Thanks @Andrew for insightful reply. So to conclude, as with remote/forcetk, if oauth tokens and client id in Javascript are fine, so should be the API keys ? – Abhinav Gupta Jul 25 '14 at 16:48
  • It really depends on how concerned you would be if someone got hold of them and started making API calls effectively as "your app", personally i would have said it's pretty dangerous stuff to share tbh. – Andrew Fawcett Jul 25 '14 at 16:52

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.