To outline the steps required to configure a Moodle development instance (verified on Moodle 4.5) to permit outbound HTTP requests using Moodle’s curl wrapper (lib/filelib.php) to services running on localhost (e.g., 127.0.0.1, ::1).

2. Background

Moodle includes security features (controlled via Site administration > General > Security > HTTP security) to prevent Server-Side Request Forgery (SSRF). By default, requests to reserved IP addresses (like 127.0.0.1 for localhost) are often blocked by the \core\files\curl_security_helper unless specific configurations are made.

3. Procedure (Moodle 4.x UI Method – Preferred for Dev)

This method uses the Moodle administration interface found at Site administration > General > Security > HTTP security.

  1. Configure Blocked Hosts: Locate the setting “cURL blocked hosts list” (config variable $CFG->curlsecurityblockedhosts).

    • For local development only, ensure this list is LEFT EMPTY. This prevents localhost (and its corresponding IPs 127.0.0.1, ::1) from being blocked by the system’s check for reserved addresses.

    • Production Warning: On a production server, this list SHOULD NOT be empty. It should contain reserved/internal IP ranges (e.g., 198.51.100.10/8, ::1/128, 198.51.100.11/8, 198.51.100.12/12, 198.51.100.13/16) to maintain security. Only remove specific entries from a comprehensive blocklist if absolutely necessary for trusted internal communication.

  2. Configure Allowed Ports: Locate the setting “cURL allowed ports list” (config variable $CFG->curlsecurityallowedport).

    • Ensure the standard web ports 80 and 443 are present (usually on separate lines).

    • ADD the specific non-standard port your local service uses (e.g., 8000) to this list (e.g., on a new line). If this list has entries, Moodle will block requests to any port not on the list.

  3. Save: Click “Save changes”.

  4. Purge Caches: Go to Site administration > Development > Purge all caches.

4. Procedure (config.php Method – Alternative/Fallback)

Use this only if the UI settings are inaccessible or for scripted setups.

  1. Edit config.php: Open the main Moodle config.php file.

Add/Modify Configuration: After

require_once(__DIR__ . '/lib/setup.php');:
// --- cURL Security Settings for Localhost Development ---

// Define allowed ports, including your development port (e.g., 8000).

$CFG->curlsecurityallowedport = ’80, 443, 8000′; // Comma or newline separated

// Define blocked hosts list as EMPTY for development to allow localhost.

$CFG->curlsecurityblockedhosts = '';
// --- End cURL Security Settings ---
  1. Save config.php.

  2. Purge Caches.

5. Security Reminder

  • This configuration (empty blocklist) is for development environments only. It disables a key SSRF protection mechanism for local addresses.

  • Never use an empty blocklist on production servers. Configure it appropriately with reserved ranges.

6. Verification

  • Retry your plugin’s cURL request to localhost:[port].

  • Use Moodle Developer debugging if issues persist.

Solin helps development teams make Moodle environments practical to work with while keeping production safeguards intact. Need help? Contact us.

Contact us