A plugin that fetches a feed URL entered by a user is a server-side request forgery waiting to happen: the URL can be http://127.0.0.1:11211/, or the private address of the database server, and the response comes back through your application. wp_safe_remote_get() is the same function with the URL validated first.
$url = esc_url_raw( wp_unslash( $_POST['feed_url'] ) );
// fetches whatever the string says, loopback and private ranges included
$response = wp_remote_get( $url );
// validates scheme, port and resolved host — and does it again on each redirect
$response = wp_safe_remote_get( $url, array( 'timeout' => 5 ) );
if ( is_wp_error( $response ) ) {
return $response;
}
$body = wp_remote_retrieve_body( $response );The difference is a single request argument, reject_unsafe_urls, which routes the URL through wp_http_validate_url(): the scheme has to be http or https, the port has to be 80, 443 or 8080, and the host must not resolve to a loopback or private address. Re-validating on redirect is the part a hand-rolled check almost always misses, since an attacker only needs a public URL that answers 302 with an internal one. The trade is that a deliberately internal endpoint — a service on the same private network, a staging host on port 8000 — is now rejected too, and the way to allow one is the http_request_host_is_external and http_request_port filters rather than dropping back to the unsafe call. The rule is simple enough to apply without thinking: URLs your code composed use wp_remote_get(), URLs a user supplied use the safe variant.