ESLint InterlaceESLint Interlace
Plugin: browser-securityRules

require-url-validation

ESLint rule documentation for require-url-validation

📡 Live from GitHub — This documentation is fetched directly from require-url-validation.md and cached for 6 hours.

Keywords: require url validation, open redirect, security, ESLint rule, CWE-601, window.location, phishing CWE: CWE-601: URL Redirection to Untrusted Site ('Open Redirect')
OWASP Mobile: OWASP Mobile Top 10 M4: Insufficient Input/Output Validation

CWE: CWE-601

ESLint Rule: require-url-validation. This rule is part of eslint-plugin-browser-security.

Quick Summary

AspectDetails
SeverityHigh (Phishing Risk)
Auto-Fix❌ No (requires allowlist logic)
CategorySecurity
ESLint MCP✅ Optimized for ESLint MCP integration
Best ForFrontend apps handling dynamic redirects
Suggestions✅ Advice on using hostname allowlists

Vulnerability and Risk

Vulnerability: An Open Redirect vulnerability occurs when an application accepts a user-controlled input that specifies a link to an external site and uses that link in a Redirection without validation.

Risk: This can be exploited to facilitate phishing attacks. Since the initial URL appears to be from a trusted domain, users are more likely to click it, only to be redirected to a malicious site that looks identical to the original.

Error Message Format

The rule provides LLM-optimized error messages (Compact 2-line format) with actionable security guidance:

🔒 CWE-601 OWASP:M4 | URL Validation Required detected | HIGH [OpenRedirect,Phishing]
   Fix: Validate URLs before using them for navigation | https://cwe.mitre.org/data/definitions/601.html

Message Components

ComponentPurposeExample
Risk StandardsSecurity benchmarksCWE-601 OWASP:M4
Issue DescriptionSpecific vulnerabilityURL Validation Required detected
Severity & ComplianceImpact assessmentHIGH [OpenRedirect,Phishing]
Fix InstructionActionable remediationValidate URLs before using them for navigation
Technical TruthOfficial referenceOpen Redirect

Rule Details

This rule flags direct assignments to window.location or location.href, and calls to window.open() where the URL is a variable, suggesting it might contain unvalidated user input.

Why This Matters

IssueImpactSolution
🎣 PhishingUsers tricked into giving credsUse strictly enforced allowlists for domains
🕵️ DetectionBypasses basic security filtersCheck protocol (https only) and hostname
🤝 TrustBrand integrity damageUse relative paths for redirects whenever possible

Configuration

This rule has no configuration options in the current version.

Examples

❌ Incorrect

// Direct assignment from a URL parameter
const params = new URLSearchParams(window.location.search);
const redirectUrl = params.get('next');

window.location.href = redirectUrl; // ❌ HIGH RISK

// Using window.open with an unvalidated variable
function navigate(target) {
  window.open(target, '_blank'); // ❌ HIGH RISK
}

✅ Correct

// Validating against a known allowlist
const ALLOWED_DOMAINS = ['example.com', 'docs.example.com'];

function safeNavigate(url) {
  const target = new URL(url, window.location.origin);
  if (ALLOWED_DOMAINS.includes(target.hostname)) {
    window.location.href = target.href;
  }
}

// Redirecting to relative paths only
function safeRelativeRedirect(path) {
  if (path.startsWith('/')) {
    window.location.pathname = path;
  }
}

Known False Negatives

The following patterns are not detected due to static analysis limitations:

String Concatenation

Why: If the URL is only partially user-controlled, it might not be flagged if the rule only looks for direct variable assignments.

window.location.href = 'https://example.com/login?next=' + userInput; // ❌ NOT DETECTED

Mitigation: Always sanitize and validate any user-provided string.

Object Properties

Why: If the URL is stored in an object property, the rule might miss it.

window.location.href = options.redirectUrl; // ❌ NOT DETECTED

Mitigation: Enforce strict validation at the source of the configuration.

References

On this page

No Headings