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.
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
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.
The application calls `urljoin` and returns the result without validating if the target URL starts with `//`. `urljoin` interprets protocol-relative URLs as absolute network locations, which can lead to Open Redirect vulnerabilities if the output is used in a Location header. Ensure inputs are validated (e.g., using `startswith('//')`) or explicitly constrai
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., `
Extracting a URL path by splitting on '?' ignores URL fragments ('#'). This can allow an attacker to bypass prefix-based path validation (e.g., checking if it starts with '/') by hiding payloads in the fragment or using URL-encoded whitespace, leading to vulnerabilities such as Open Redirect or SSRF. Use a robust URL parser (like `new URL()`) or ensure both
Passing an unvalidated, non-constant value to the second argument of urljoin can lead to Open Redirect or SSRF. The urljoin function treats strings starting with '//' as network-path references, which replaces the host of the base URL. Ensure the input is validated (e.g., check that it doesn't start with '//') or sanitized before calling urljoin.
Unvalidated user input is passed directly to an HTTP redirect response, which can lead to an Open Redirect vulnerability. An attacker can craft a link to the application with a malicious redirect URL, tricking users into visiting phishing sites. To fix this, validate the URL parameter using a dependency or sanitization function before passing it to RedirectR
Unsanitized user input from `router.query` or `useSearchParams()` is passed directly to `router.push()` or `router.replace()`. This can lead to Open Redirect or Cross-Site Scripting (XSS) if a `javascript:` URI is provided. Sanitize the URL before redirecting, for example using `@braintree/sanitize-url`.
Unvalidated input from query parameters is used directly in a RedirectResponse, leading to an Open Redirect vulnerability.
The application retrieves the 'authTokenSyncURL' experimental configuration but fails to verify that it represents a local domain path. An attacker who can pre-set the corresponding cookie (e.g., FIREBASE_DEFAULTS) could direct auth tokens to an external server. Ensure the URL is validated to start with '/' before usage.
Constructing a redirect URL based on a saved request without sanitizing duplicate leading slashes allows for protocol-relative URL bypasses. Attackers can supply URLs like `//malicious.site` to exploit open redirect vulnerabilities. Ensure that paths are properly sanitized so they do not begin with multiple slashes if they are evaluated relative to a root co
Unvalidated redirects occur when an application redirects a user to a destination URL specified by a user supplied parameter that is not validated. Such vulnerabilities can be used to facilitate phishing attacks.
ScalaCWE-601Unvalidated redirects occur when an application redirects a user to a destination URL specified by a user supplied parameter that is not validated. Such vulnerabilities can be used to facilitate phishing attacks. To avoid open redirect vulnerabilities in Java, one effective strategy is to only allow redirection to URLs that are pre-defined in a safe list. Th
JavaCWE-601Passing untrusted user input in `redirect()` can result in an open redirect vulnerability. This could be abused by malicious actors to trick users into being redirected to websites under their control to capture authentication information. To prevent open redirect vulnerabilities: - Always validate and sanitize user inputs, especially URL parameters or query
JSCWE-601Passing untrusted user input in `redirect()` can result in an open redirect vulnerability. This could be abused by malicious actors to trick users into being redirected to websites under their control to capture authentication information. To prevent open redirect vulnerabilities: - Always validate and sanitize user inputs, especially URL parameters or query
JSCWE-601Unvalidated redirects occur when an application redirects a user to a destination URL specified by a user supplied parameter that is not validated. Such vulnerabilities can be used to facilitate phishing attacks.
KotlinCWE-601The application may allow open redirects if created using user supplied input. Open redirects are commonly abused in phishing attacks where the original domain or URL looks like a legitimate link, but then redirects a user to a malicious site. An example would be `https://example.com/redirect?url=https://%62%61%64%2e%63%6f%6d%2f%66%61%6b%65%6c%6f%67%69%6e` w
C#CWE-601
