The redirect URL validation only compares URL scheme and host without validating the path component. An attacker could supply an arbitrary path on an allowed domain to capture OAuth codes or tokens via Referer headers, analytics scripts, or open redirects. Validate the full path or require exact URL matches.
Rule Explorer
Search the public rule index by CVE, GHSA, CWE, language, framework, author, or rule slug. Filter by language, framework, severity, confidence, license, and validation status.
- Public rules
- 4797
- Downloads
- 12M
- Verified
- 4797
- Authors
- 2
Base64-decoded input is passed directly to a redirect method without verifying that the target URL is an internal destination, which can lead to an open redirect vulnerability (CWE-601).
Matching domains or hostnames using `String.endsWith()` without a dot boundary allows attackers to bypass validation by registering a domain that has the target domain as a suffix (e.g., `evil-example.com` will match `example.com`). Require a dot-prefixed match, or use an exact match (`equals`).
HTML scrubber configuration allows 'formaction' or other form override attributes. Allowing 'formaction' in sanitized HTML permits attackers to override form actions and redirect submissions to external malicious domains.
The list of invalid local URL characters contains backslashes but omits tab, newline, or carriage return characters. Web browsers strip whitespace characters like ASCII tab (\t or %09) prior to parsing URLs, allowing attackers to bypass leading '//' checks and trigger open redirects.
OAuth redirect URI is dynamically constructed from untrusted HTTP Host header. Use a configured server base URL instead to prevent Host header poisoning.
A function parameter is passed directly to `RedirectResponse` without explicit safe-listing or encoding. If this parameter is user-controllable, it causes an Open Redirect and potentially Client-Side Server-Side Request Forgery (SSRF). To fix, validate the URL against a strict allow-list, use safe proxies for retrieving resources, or avoid redirecting unvali
OAuth2 authorization code error handling does not suppress redirects when an invalid request_uri parameter is provided. An attacker can supply an invalid request_uri with an arbitrary redirect_uri, leading to an open redirect vulnerability.
Invitation or activation link is constructed without validating trusted host headers via refuseIfUntrustedHost(), allowing host header poisoning.
A URL object is instantiated to validate the path, but the host is not verified. Attackers can supply protocol-relative paths (e.g., `//evil.com`) which resolve against the current base URL and pass protocol-only checks. If the unvalidated path is then used for navigation, it results in an Open Redirect.
Reconstructing a relative URL directly from `URL.pathname` without sanitizing leading slashes can lead to Open Redirect vulnerabilities. When parsing user input with a dummy base, inputs like `/.//evil.com` normalize to a pathname of `//evil.com`. If this is used in a navigation or redirect, it is treated as a protocol-relative URL to an external domain. Col
Validating local redirects by checking the 'host' key from `parse_url()` without sanitizing backslashes (`\`) is vulnerable to Open Redirect. Browsers normalize backslashes to forward slashes, meaning payloads like `/\attacker.com` will be evaluated as a relative path by `parse_url()` (leaving 'host' empty) but as an external redirect by the browser. Sanitiz
Checking for protocol-relative URLs with startswith() without stripping leading whitespace or C0 control characters allows bypasses when followed by urllib.parse.urljoin(), potentially leading to open redirects (CVE-2026-54770).
Client-controlled redirect target from `_redirect` is used in `setRedirect()` without validating that the target is internal using `!Uri::isExternal()`.
Relying on `URI.isAbsolute()` to validate redirect URLs is unsafe because protocol-relative URLs (e.g., `//evil.com`) lack a scheme and cause `isAbsolute()` to return false. Redirecting to such URLs can lead to open redirect vulnerabilities.
Constructing a new HTTP request directly from an unvalidated Location header can lead to credential leakage via open redirects to attacker-controlled hosts.
A weak blocklist (checking only for newlines and null bytes using `strpbrk`) is used to sanitize URLs. This may allow attackers to supply unexpected URI characters (such as backslashes) to bypass downstream domain checks or relative-path validations, potentially causing open redirects. Implement a strict allowlist of valid URI characters instead.
Using `urljoin` to make a path absolute is vulnerable to protocol-relative open redirects. If the value starts with `//`, `urljoin` treats it as a network location, overriding the base domain. Ensure the suffix does not start with `//` or sanitize it before joining.
Direct use of an unvalidated `redirect_uri` from a request payload in an error response class leads to an Open Redirect vulnerability. An attacker can manipulate the URL to silently redirect victims to untrusted domains. Validate the URI against the registered client via `check_redirect_uri` prior to use.
Unvalidated user input flows into an HTTP redirect or a template execution without proper escaping. This causes Open Redirect or Cross-Site Scripting (XSS). Ensure destination URLs are validated to be relative paths, and ensure `html/template` is used instead of `text/template`.
Validation of a URL using raw string pattern matching allows bypasses by embedding allowed patterns in the userinfo section of a URL (e.g., `http://allowed-domain@attacker.com`). Parse the URL first using `new URL()` and validate its `host`, `hostname`, or `origin`.
The HTML cleaner fails to reliably remove `<base>` tags when removing `<head>` tags. This omission allows attackers to inject rogue `<base>` elements that bypass sanitization, potentially hijacking relative URLs and triggering cross-site scripting (XSS) or malicious redirects upon rendering.
Validating an origin or domain by checking if a string starts with an allowed origin is insecure. An attacker can bypass this check by registering a domain that shares the same prefix (e.g., `https://target.com.attacker.com` starts with `https://target.com`). Parse the input using `new URL()` and check for exact equality against `url.origin` or `url.hostname
A string field or variable is concatenated into a URL/URI hostname without format validation. An attacker who can influence this value can inject extra domain labels, '@'-sign user-info, or URL-special characters, enabling SSRF or open-redirect attacks (e.g., hijacking an OAuth authorization flow). Validate the input against a strict allowlist regex (e.g., `