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