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.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?

  • 2
    In my opinion, it is not secure to pass sensitive info in params for GET request. I would suggest to implement rest resource in External System, that accepts POST request, too. Commented Jul 19, 2021 at 9:45

1 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.

  • Overall I agree but I want to point out that snehakem does clarify that they make the callout server-side in Apex. Commented Jul 19, 2021 at 12:11
  • 1
    @Victor L There is one thing that's mentioned that server does log clientid and secrets and that's concerning to me. I think that's why these questions are good to ask in office hours of security review.What I would do is if I can modify the service to use POST just to be safe! Commented Jul 19, 2021 at 12:14
  • 1
    Understood! It's important info to have - just wanted to make clear for anyone skimming through really. :) Commented Jul 19, 2021 at 12:15
  • Thanks for your inputs @MohithShrivastava . We will reach out to office hours as you suggested.
    – snehakem
    Commented Jul 19, 2021 at 12:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .