How to handle sensitive parameters to curl_setopt?

On Sat, Aug 1, 2026 at 10:11 PM Sjoerd Langkemper sjoerd-php@linuxonly.nl
wrote:

Hello list,

I would like to reduce the chance that sensitive information passed to
curl_setopt is leaked. There's the SensitiveParameter attribute to prevent
parameters being exposed in stack traces. For example, openssl_encrypt has
its passphrase parameter marked as SensitiveParameter, so it won't be shown
in a stack trace. This mechanism doesn't work so well for curl_setopt,
which has the ability to set many options, both sensitive and not. The
value for CURLOPT_PASSWORD is likely sensitive, the value for
CURLOPT_RETURNTRANSFER is not, and CURLOPT_URL may be sensitive sometimes.

I have thought of the following solutions:

1. Mark the parameter as SensitiveParameter. This improves security,
   but also obscures non-sensitive information. I am not sure how big of a
   disadvantage that actually is? The curl error messages could already use
   improvement, but when the value is hidden (because it's sensitive) it
   becomes even more important to provide better errors.
2. Let curl_setopt determine whether to mark the parameter as
   sensitive, depending on which option is being set. This is nice
   functionally, but needs changes in the engine to store sensitivity of each
   parameter in the stack, which comes with performance costs.
   https://github.com/php/php-src/pull/22938
3. Be able to pass a SensitiveParameterValue to curl_setopt. This puts
   the burden on the user to correctly wrap their sensitive values.
   https://github.com/php/php-src/pull/22960

What do you think?

Regards,

Sjoerd

Stack traces are available on dev machines only unless everything is
misconfigured so I don't see how it can leak something. Imagine you
request an API with the wrong password because a co-worker changed it. How
would you know? Just my 2 cents.

--
Iliya Miroslavov Iliev
i.miroslavov@gmail.com

On Sat, Aug 1, 2026, 2:09 PM Sjoerd Langkemper sjoerd-php@linuxonly.nl
wrote:

Hello list,

I would like to reduce the chance that sensitive information passed to
curl_setopt is leaked. There's the SensitiveParameter attribute to prevent
parameters being exposed in stack traces. For example, openssl_encrypt has
its passphrase parameter marked as SensitiveParameter, so it won't be shown
in a stack trace. This mechanism doesn't work so well for curl_setopt,
which has the ability to set many options, both sensitive and not. The
value for CURLOPT_PASSWORD is likely sensitive, the value for
CURLOPT_RETURNTRANSFER is not, and CURLOPT_URL may be sensitive sometimes.

I have thought of the following solutions:

1. Mark the parameter as SensitiveParameter. This improves security,
   but also obscures non-sensitive information. I am not sure how big of a
   disadvantage that actually is? The curl error messages could already use
   improvement, but when the value is hidden (because it's sensitive) it
   becomes even more important to provide better errors.
2. Let curl_setopt determine whether to mark the parameter as
   sensitive, depending on which option is being set. This is nice
   functionally, but needs changes in the engine to store sensitivity of each
   parameter in the stack, which comes with performance costs.
   https://github.com/php/php-src/pull/22938
3. Be able to pass a SensitiveParameterValue to curl_setopt. This puts
   the burden on the user to correctly wrap their sensitive values.
   https://github.com/php/php-src/pull/22960

Not optimal, but some other options, all requiring userland intervention:

• Additional optional boolean flag parameter to curl_setopt that, when
  true, indicates that the value provided is sensitive and which flags to the
  engine to wrap it in SensitiveParameter.
• An integer constant that you | into the option name; when detected, the
  engine wraps the provided value argument in SensitiveParameter.
• Allow the engine to accept SensitiveParameter instances directly to any
  function call. This would allow users to opt-in regardless of the function
  signature.

The problem with curl_setopt is that auto detection will be difficult and a
game of whack-a-mole - considering opts are how you set HTTP headers and
content, which can be arbitrary. Allowing the user to determine what is and
isn't sensitive would allow more flexibility, and play nice with the
observer API for precisely the security use cases you describe.

--
Matthew Weier O'Phinney
mweierophinney@gmail.com
https://mwop.net/
he/him