API_URL Defaults to HTTP Without HTTPS Enforcement

The Vulnerability Explained

The API client in this application ships with a critical but silent flaw: its default API endpoints default to HTTP, not HTTPS. This means that when the application makes requests to fetch project data, authentication tokens, or other sensitive information, that traffic travels in plaintext across the network.

Consider the default configuration: http://localhost:3000. On a production server or across any untrusted network, this is an open invitation to passive and active network attacks. An attacker positioned on the same network—whether physical Wi-Fi, a compromised ISP router, or a cloud infrastructure hypervisor—can read, modify, or replay every API request without breaking a single authentication mechanism.

The irony is that a helper function to enforce HTTPS already existed in the codebase:

// src/api.js:55-59
function upgradeToHttps(url) {
    // Helper exists but is not applied everywhere
}

However, this helper was applied inconsistently. The fetchWithRetry() function—the main retry logic for robust API calls—did not upgrade URLs before sending them. Neither did direct fetch calls in the songUrl() method. This inconsistency meant that even if one code path was protected, another remained exposed.

Affected Versions

Attack Scenario

A developer deploys this application to a production cloud environment. The API_URL defaults to http://localhost:3000, or perhaps a similarly insecure scheme. A network-level attacker—for example, a compromised cloud neighbor, a rogue ISP, or an actor on a shared VPN—observes the following unencrypted request:

GET http://api.example.com/project/data?id=12345 HTTP/1.1
Authorization: Bearer eyJhbGc...

The attacker now has:
- The bearer token (replay attacks, token forgery)
- The project ID (enumeration, targeted attacks)
- The internal API schema (reverse engineering)
- A record of when the application communicates (timing attacks, inference)

None of this requires breaking authentication. The plaintext channel does the work.

The Fix

The fix is direct: apply upgradeToHttps() consistently before every fetch call. Two changes were needed:

Change 1: Upgrade URLs in fetchWithRetry()

// Before
async function fetchWithRetry(url, options = {}, retryConfig = config.retry) {
    const { maxRetries, baseDelay } = retryConfig;
    let lastError;
    // url is used as-is, HTTP not enforced
}

// After
async function fetchWithRetry(url, options = {}, retryConfig = config.retry) {
    const { maxRetries, baseDelay } = retryConfig;
    let lastError;
    url = upgradeToHttps(url);  // <-- Enforce HTTPS before retry loop
}

fetchWithRetry() is the application's main mechanism for resilient API calls. By upgrading the URL at the entry point, every request retried through this function is now protected, regardless of which retry attempt succeeds.

Change 2: Upgrade URLs in songUrl()

// Before
async songUrl(id, br) {
    const url = this.buildUrl({ server: 'netease', type: 'url', id, br });
    const response = await fetch(url, {
        method: 'GET',
        redirect: 'follow',
    });
}

// After
async songUrl(id, br) {
    const url = upgradeToHttps(this.buildUrl({ server: 'netease', type: 'url', id, br }));
    const response = await fetch(url, {
        method: 'GET',
        redirect: 'follow',
    });
}

Direct fetch calls that bypass the retry wrapper now also enforce HTTPS. This is especially important for the songUrl() method, which requests media metadata—sensitive data that should not travel in the clear.

Why Both Changes Were Necessary

The retry wrapper handles most cases, but not all. If songUrl() or other methods call fetch() directly, they bypass fetchWithRetry() entirely. The attacker could target these direct calls, leaving a security gap. By applying the upgrade in both places, the fix ensures defense-in-depth: no matter which code path executes, HTTPS is enforced.

How Orbis AppSec Detected This

Source: The API_URL and BASE_URL configuration parameters, which default to unencrypted schemes (http://localhost:3000).

Sink: Direct fetch() calls and the fetchWithRetry() function, which transmit these URLs without scheme validation.

Missing control: No automatic, mandatory upgrade of insecure schemes before the fetch() call, even though an upgradeToHttps() helper existed but was not universally applied.

CWE: CWE-319: Cleartext Transmission of Sensitive Information.

Fix: Invoke upgradeToHttps() at the entry point of fetchWithRetry() and on the result of buildUrl() in songUrl() before passing the URL to fetch().

Orbis AppSec automatically detected this vulnerability and opened a pull request with the fix. Try Orbis AppSec on your repositories to find and fix issues like this automatically.

Key Takeaways

• Inconsistent application of security helpers is a vulnerability. If an upgradeToHttps() function exists but only some code paths use it, the unprotected paths become attack surface. Security controls must be applied uniformly or enforced at a layer that applies to all code paths (e.g., at the HTTP client library level).

• Default configurations must not expose sensitive data. Defaulting to HTTP is worse than requiring explicit HTTPS opt-in, because developers will ship the defaults without realizing the risk. Always default to the secure option.

• Configuration is not a substitute for code-level enforcement. Even if documentation says to configure API_URL as HTTPS, the code should not allow HTTP to succeed silently. Validate and upgrade schemes in the code, not just in environment variable instructions.

• Network attackers do not need to break authentication to steal data. Plaintext protocols expose authentication tokens, session cookies, API keys, and request contents directly. Encryption is a prerequisite for authentication, not an alternative.

Conclusion

The fix ensures that all API communications—whether retried through fetchWithRetry() or sent directly via songUrl()—are protected by HTTPS before they leave the application. By applying the existing upgradeToHttps() helper consistently, the application closes the window for network-level interception of sensitive project data and authentication credentials. This change exemplifies why security utilities must be applied uniformly across the codebase, and why defaults should never sacrifice confidentiality.