Re: [PHP-DEV] How to handle sensitive parameters to curl_setopt?

--00000000000002d19c065802d328
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Aug 1, 2026, 2:09=E2=80=AFPM Sjoerd Langkemper <sjoerd-php@linuxonl=
y.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 preven=
t
> parameters being exposed in stack traces. For example, openssl_encrypt ha=
s
> its passphrase parameter marked as SensitiveParameter, so it won't be sho=
wn
> 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 u=
se
>    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.

--=20
Matthew Weier O'Phinney
[email protected]
https://mwop.net/
he/him

--00000000000002d19c065802d328
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><div><br></div><div><br></div><br><br><div class=3D"=
gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On=
 Sat, Aug 1, 2026, 2:09=E2=80=AFPM Sjoerd Langkemper &lt;<a href=3D"mailto:=
[email protected]">[email protected]</a>&gt; wrote:<br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><u></u><div><div>Hello list,</div><div><br></d=
iv><div>I would like to reduce the chance that sensitive information passed=
 to curl_setopt is leaked. There&#39;s the SensitiveParameter attribute to =
prevent parameters being exposed in stack traces. For example, openssl_encr=
ypt has its passphrase parameter marked as=C2=A0SensitiveParameter, so it w=
on&#39;t be shown in a stack trace. This mechanism doesn&#39;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.=
</div><div><br></div><div>I have thought of the following solutions:<br></d=
iv><ol><li>Mark the parameter as=C2=A0SensitiveParameter. This improves sec=
urity, but also obscures non-sensitive information. I am not sure how big o=
f a disadvantage that actually is? The curl error messages could already us=
e improvement, but when the value is hidden (because it&#39;s sensitive) it=
 becomes even more important to provide better errors.</li><li>Let curl_set=
opt determine whether to mark the parameter as sensitive, depending on whic=
h 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 wit=
h performance costs.=C2=A0<a href=3D"https://github.com/php/php-src/pull/22=
938" target=3D"_blank" rel=3D"noreferrer">https://github.com/php/php-src/pu=
ll/22938</a><br></li><li>Be able to pass a=C2=A0SensitiveParameterValue to =
curl_setopt. This puts the burden on the user to correctly wrap their sensi=
tive values.=C2=A0<a href=3D"https://github.com/php/php-src/pull/22960" tar=
get=3D"_blank" rel=3D"noreferrer">https://github.com/php/php-src/pull/22960=
</a></li></ol></div></blockquote></div></div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto">Not optimal, but some other options, all requiring userland=
 intervention:</div><div dir=3D"auto"><br></div><div dir=3D"auto">- Additio=
nal optional boolean flag parameter to curl_setopt that, when true, indicat=
es that the value provided is sensitive and which flags to the engine to wr=
ap it in SensitiveParameter.</div><div dir=3D"auto">- An integer constant t=
hat you | into the option name; when detected, the engine wraps the provide=
d value argument in SensitiveParameter.=C2=A0</div><div dir=3D"auto">- Allo=
w the engine to accept SensitiveParameter instances directly to any functio=
n call. This would allow users to opt-in regardless of the function signatu=
re.</div><div dir=3D"auto"><br></div><div dir=3D"auto">The problem with cur=
l_setopt is that auto detection will be difficult and a game of whack-a-mol=
e - considering opts are how you set HTTP headers and content, which can be=
 arbitrary. Allowing the user to determine what is and isn&#39;t sensitive =
would allow more flexibility, and play nice with the observer API for preci=
sely the security use cases you describe.=C2=A0</div><div dir=3D"auto"><br>=
</div><div dir=3D"auto">--=C2=A0</div><div dir=3D"auto">Matthew Weier O&#39=
;Phinney</div><div dir=3D"auto"><a href=3D"mailto:[email protected]"=
>[email protected]</a></div><div dir=3D"auto"><a href=3D"https://mwo=
p.net/">https://mwop.net/</a></div><div dir=3D"auto">he/him</div><div dir=
=3D"auto"></div></div>

--00000000000002d19c065802d328--