GET Request with Client ID and Client Secret as Parameter

Question

We are working on an AppExchange app which integrates with 3rd Party application. To connect external app with Salesforce, a Subscriber System admin needs to connect External System using Client Id/Client Secret.

As of now External System is only supporting GET call which accepts ClientId and Client Secret.

e.g. ClientID and ClientSecret entered on a Salesforce Screen, which is passed as a parameter for the GET Callout. Below is the sample code snippet:

HTTPRequest req = new HTTPRequest();

req.setEndpoint('https://www.example.com/api?client_id='+clientId+'&client_secret='+clientSecret);

req.setHeader( 'Content-Type', 'application/json' );

It means a GET call will be sent from Salesforce server side (through Apex) to Example.com's API. No user can see the URL in inspector or browser logs (Developer console) as we are doing GET callout from Server Side and not client side.

But, the GET Call which contains "Client ID" and "Client Secret", can be logged in URLs on the Server Logs, as this calls are happening from Server (Salesforce) To Server (example.com).

Can someone please confirm that the GET request with ClientId/ClientSecret, which are sent from Salesforce server (through Apex code) to External sites, needs to be changed to a POST call and the ClientId/Secret key needs to be passed as a RequestBody instead of URL?

Answer 1

I suggest you bring this up in an office hour with the security review team and see what they suggest to be sure that your app won't fail the security review process.

Now to answer it,

Server to Server invocation

Usually, the risk is very low if your connection is secured HTTPS from a theoretical perspective. In theory, an HTTPS connection does encrypt the URL parameters.

If you are doing it in apex and your secrets are in protected custom metadata or settings I think it's ok.

A note to the service provider of the API

The service can be invoked via client-side JavaScript. Hence service provider should change to use a POST instead of GET calls.

For example, in the browser, if screens are recorded then one can see the URL parameter or in the browser history this will show up and the credentials are then compromised if the browser is shared.

Also logging client secret and client in the server via debug logs can be risky. If the server is not protecting these logs and they show up then this is a big security risk.

I would reach back to the external service provider and ask them to change to POST calls to mitigate any security risks.