# How to handle sensitive parameters to curl_setopt? - Thread: https://externals.io/message/132160 - Original archive: https://news-web.php.net/php.internals/132160 - Started by Sjoerd Langkemper on 2026-08-01T19:07:34+00:00 - Messages: 3 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #132160 — Sjoerd Langkemper — 2026-08-01T19:07:34+00:00 URL: https://externals.io/message/132160#132160 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 --- ## #132161 — Iliya Miroslavov Iliev — 2026-08-01T19:29:36+00:00 URL: https://externals.io/message/132160#132161 · In reply to: #132160 On Sat, Aug 1, 2026 at 10:11 PM Sjoerd Langkemper 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 --- ## #132162 — Matthew Weier O'Phinney — 2026-08-01T21:16:42+00:00 URL: https://externals.io/message/132160#132162 · In reply to: #132160 On Sat, Aug 1, 2026, 2:09 PM Sjoerd Langkemper 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