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
| Aspect | Details |
|---|---|
| Severity | High (Phishing Risk) |
| Auto-Fix | ❌ No (requires allowlist logic) |
| Category | Security |
| ESLint MCP | ✅ Optimized for ESLint MCP integration |
| Best For | Frontend 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.htmlMessage Components
| Component | Purpose | Example |
|---|---|---|
| Risk Standards | Security benchmarks | CWE-601 OWASP:M4 |
| Issue Description | Specific vulnerability | URL Validation Required detected |
| Severity & Compliance | Impact assessment | HIGH [OpenRedirect,Phishing] |
| Fix Instruction | Actionable remediation | Validate URLs before using them for navigation |
| Technical Truth | Official reference | Open 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
| Issue | Impact | Solution |
|---|---|---|
| 🎣 Phishing | Users tricked into giving creds | Use strictly enforced allowlists for domains |
| 🕵️ Detection | Bypasses basic security filters | Check protocol (https only) and hostname |
| 🤝 Trust | Brand integrity damage | Use 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 DETECTEDMitigation: 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 DETECTEDMitigation: Enforce strict validation at the source of the configuration.