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.
Detected a fallback to a wildcard ('*') when evaluating a list of CORS origins that has a length greater than 1. This incorrectly exposes the endpoint to Cross-Origin Resource Sharing (CORS) from any domain if multiple origins are provided. Instead of enforcing multi-origin protections, the fallback strips all security by providing an unrestricted wildcard p
A wildcard `*` is hardcoded as the value for the `Access-Control-Allow-Origin` header in `send_header`. This permissive CORS policy allows any origin to read the response. If the HTTP server exposes sensitive data or APIs, this can result in cross-origin data exfiltration via simple requests or preflight bypasses. Configure allowed origins explicitly instead
The application or middleware is configured to allow CORS with wildcard origins (`["*"]`) combined with `allow_credentials=True`. Starlette's CORSMiddleware natively resolves this by reflecting the underlying incoming Origin header into the response, circumventing strict web standards and enabling malicious sites to forge cross-origin interactions using the
Potential OS command injection: a template literal builds a shell command using `cd "${...}"` (or `Set-Location -Path "${...}"`) followed by additional `${...}` interpolations. If any interpolated value is attacker-controlled (e.g. taken from a request body, WebSocket payload, or query parameter), shell metacharacters in the value will break out of the quote
The server employs an overly permissive CORS configuration by hardcoding `"*"` in `AllowedOrigins`. This exposes the application to unintended cross-origin interactions. If the server lacks Host header validation and runs on localhost, this enables DNS rebinding attacks to access sensitive local data. Use a strictly validated, configurable list of allowed or
The CORS middleware blindly returns the configured origin string when it is a single element without validating it against the incoming request's Origin header. When using wildcard defaults with enabled credentials, underlying libraries may reflect the Origin header unconditionally, leading to a CORS bypass (CVE-2025-53092).
Insecure origin validation using a substring match. When validating CORS origins without a protocol schema, using a substring match logic (`.includes` or `indexOf`) allows attackers to bypass restrictions by using a malicious domain that unexpectedly contains the allowed origin as a substring (e.g., `notexample.com` bypasses `example.com`). Use exact string
An insecure wildcard CORS origin (`*`) was found in an Nginx configuration. This allows any cross-origin site to access resources and API responses. Remove the wildcard origin to enforce the same-origin policy, or restrict it to trusted, specific domains.
A permissive CORS configuration was detected. Setting `allow_origins` to include `"*"` allows requests from any origin. If this server runs on localhost or inside a private network, this exposes the API to Cross-Site Read (CORS) attacks, potentially leaking sensitive information to attacker-controlled websites. Use specific origins driven by configuration in
A CORS misconfiguration allows overly permissive cross-origin requests. The flask-cors CORS module is instantiated without origin restrictions, allowing all domains by default. Attackers can exploit this to steal sensitive information or perform unauthorized actions on behalf of a user. Ensure you explicitly configure restricted domains using 'origins' or 'r
Prior to HTML5, Web browsers enforced the Same Origin Policy which ensures that in order for JavaScript to access the contents of a Web page, both the JavaScript and the Web page must originate from the same domain. Without the Same Origin Policy, a malicious website could serve up JavaScript that loads sensitive information from other websites using a clien
JavaCWE-942Prior to HTML5, Web browsers enforced the Same Origin Policy which ensures that in order for JavaScript to access the contents of a Web page, both the JavaScript and the Web page must originate from the same domain. Without the Same Origin Policy, a malicious website could serve up JavaScript that loads sensitive information from other websites using a clien
KotlinCWE-942Prior to HTML5, Web browsers enforced the Same Origin Policy which ensures that in order for JavaScript to access the contents of a Web page, both the JavaScript and the Web page must originate from the same domain. Without the Same Origin Policy, a malicious website could serve up JavaScript that loads sensitive information from other websites using a clien
ScalaCWE-942This application potentially allows user-supplied input into the value of the `Access-Control-Allow-Origin` response header. This header is part of the [Cross-Origin Resource Sharing](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) CORS specification. By allowing user input to specify which domains can communicate with this server, an adversary could
JavaCWE-942
