Description

In packages/net-policy/src/redact-sensitive-url.ts, the fallback URL query parameter redactor in redactSensitiveUrlLikeString matches parameters using a regular expression:

  const redactedFallback = value
    .replace(/\/\/([^@/?#\s]+)@/g, "//***:***@")
    .replace(/([?&])([^=&]+)=([^&]*)/g, (match, prefix: string, key: string) =>
      isSensitiveUrlQueryParamName(key) ? `${prefix}${key}=***` : match,
    );

The regex /([?&])([^=&]+)=([^&]*)/g splits parameters by &. However, if a query parameter contains a nested URL as its value (e.g. ?redirect_url=https://example.com/login?token=secret), the regex matches ?redirect_url=https://example.com/login?token=secret.
Because redirect_url is not classified as a sensitive parameter name, the callback returns the entire matched substring untouched.

Impact

The nested parameter token=secret completely escapes redaction and is leaked into logs, creating a serious security issue when URLs are passed as arguments to redirect/auth paths.

Suggested Fix

Perform nested parameter parsing or recursively scan query parameter values for nested query structures to ensure all layers of parameter lists are redacted.