Hi Sjoerd, Thanks for reopening this discussion ! I planned to do it in the coming days too, I'm really eager to see this land in PHP :) I'm pretty open about the 2 ways to implement it, however the discussion on 23657 about 22159 suggested a socket class bound to curl only, to make things easier to manage and to remove the dependency to ext/socket.
In my opinion, CURLOPT_OPENSOCKETFUNCTION with the boolean may be a good idea. I'm not sure there is a real use case to open a wider support in PHP - this option exists for almost 2 decades and I'm not sure anyone needed it. For the record I plan to implement the feature in a polyfill extension - with the same approach that we'll retain for PHP, to offer support in lower php versions. There are a lot of small details we can discuss if we retain the OPENSOCKET_FUNCTION: the signature may be expanded to offer the same level of data as curl offers <https://curl.se/libcurl/c/CURLOPT_OPENSOCKETFUNCTION.html>. This would make things easier if we want to support a full `CurlSocket` object later. There is a first draft here: https://github.com/xavierleune/curl-hardening My idea was to use this extension as a sandbox before pushing a new discussion here, I will follow the API we may agree on for PHP 8.7. I think the approach in the current extension may address the concerns expressed by Bukka on 22159, while giving room to expand the support later. Do you think this approach is worth pursuing ? Thanks, Xavier Le jeu. 15 oct. 2026 à 10:48, Sjoerd Langkemper <[email protected]> a écrit : > If an application performs HTTP requests based on user input, it is often > desirable to verify that the connection is done to an allowed host. > Otherwise the functionality could be abused to request resources on the > server or on the same network as the server (SSRF). > > Xavier Leune made some pull requests to make this possible in curl. The > idea is to hook in a callback that can verify the IP address that curl is > going to connect to. > > 22159: exposes callbacks such as CURLOPT_OPENSOCKETFUNCTION. These are > supported by curl, but exposing the socket to userland comes with problems. > 23657: introduces CURLOPT_PRECONNECTFUNCTION. This is not supported by > curl and is PHP-only, deviating from the normally thin abstraction on top > of curl. > > The current plan is to expose only CURLOPT_OPENSOCKETFUNCTION with the > signature function(string $address, int $port): bool. This is pretty > limited compared with what OPENSOCKETFUNCTION can normally do, but at > least makes it possible to do SSRF protection. > > What do you think? How can we expose SSRF protection to applications that > perform curl requests? > > Regards, > > Sjoerd Langkemper > >
