0

Custom code written for the Salesforce platform is incapable of making a PATCH request to an external server (PUT and POST are okay though), and I need to make a PATCH request to an external service (Microsoft Graph).

While authentication can be handled with a POST request directly from SF to MSG, obtaining the access token, I can't make the second callout, which is a PATCH. So for that, I wrote a simple Heroku-based Flask application that receives a POST request and then uses the Requests library to make the PATCH request to MSG.

From a practical point of view, this works as intended. However, from a security point of view, I would like to confirm if it is safe to assume that this approach is safe as well.

The Heroku dyno receives a POST containing the token, the endpoint to call and a "payload" which is the exact JSON I'd send to MSG directly. Of course, the connection to the dyno is secured through HTTPS, and the SF administrator has access to the URL (but not the dyno's code or repository). This way, the Flask app knows who to call, which token to use, and what is the JSON data to send.

Given that the dyno doesn't store anything, and simply forwards the callouts, could this be considered a safe approach?

  • 1
    A secure as any HTTP reverse proxy can be. That's basically what your Flask App is. – Laiv Mar 30 at 20:12
2

It depends...

From a data perspective it is doubtful that anyone could learn anything from your system. So mostly data-leak safe.

From a control perspective, there is a possibility that a flaw in the app could be exploited to allow an attacker process (or higher) level access. This is probably unlikely unless the http framework you are using has a known flaw. As long as you keep it patched this should be a low issue.

From a Denial o service perspective, someone could send a sufficient volume of request to your proxy to either overload it, or at least expend your cloud credit. It would be best if you lock the proxy down to only accept requests coming from your sales-force app itself. If you can do this at a network level great, but atleast do it at the service level.

From a Data Laundering perspective, someone could use the proxy to forward data to services either in an attempt to break into them, or in an attempt to avoid detection. Aside from ensuring that you know who has sent you the data, it would serve to restrict where that data can be sent, and what it may contain. Also generate an audit log so that when something does happen, you can at least point fingers and figure out how to improve.

So security enhancements:

  • lock down request sources, and request targets
  • restrict permitted content
  • audit each proxy (who, where, what, when, etc...)
  • keep the proxy well patched

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.