Return to Answer

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 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 service provider of the API

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

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 browser is shared.

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

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

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.

I suggest you bring this up in an office hour with the security review team and see what they suggest.

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

However the risk is high in practice if you are calling these via a client side JavaScript. The users browser can be compromised.

Example in the browser if screens are recorded then one can see the url Params or in the browser history this will show up and the credentials are then compromised.

Also logging them in the sever can be risky. If server is not protecting these logs and they show up then this is a risk.

However if you are doing it in apex and your secrets are in protected custom metadata or settings risk is significantly low.

I would personally move to POST to mitigate some of the above risks.

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 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 service provider of the API

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

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 browser is shared.

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

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

I suggest you bring this up in an office hour with the security review team and see what they suggest.

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

However the risk is high in practice. The users browser can be compromised.

Example in the browser if screens are recorded then one can see the url Params or in the browser history this will show up and the credentials are then compromised.

Also logging them in the sever can be risky. If server is not protecting these logs and they show up then this is a risk.

I would personally move to POST to mitigate some of the above risks.

I suggest you bring this up in an office hour with the security review team and see what they suggest.

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

However the risk is high in practice if you are calling these via a client side JavaScript. The users browser can be compromised.

Example in the browser if screens are recorded then one can see the url Params or in the browser history this will show up and the credentials are then compromised.

Also logging them in the sever can be risky. If server is not protecting these logs and they show up then this is a risk.

However if you are doing it in apex and your secrets are in protected custom metadata or settings risk is significantly low.

I would personally move to POST to mitigate some of the above risks.