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.
CORS is configured with `origin: true` (which reflects any request origin) together with `credentials: true`. This allows any untrusted domain to make authenticated cross-origin requests and access sensitive data. Use an explicit origin whitelist or origin validation function instead of reflecting the Origin header.
CORS is configured to unconditionally allow any origin while enabling credentials. Reflecting arbitrary request origins with 'credentials: true' allows attackers on third-party sites to execute credentialed cross-origin requests and access sensitive user data.
A wildcard CORS policy ('Access-Control-Allow-Origin': '*') was statically set on an HTTP response. When applied to APIs without robust authentication mechanisms in place, this broad permissiveness allows any origin to bypass the Same-Origin Policy. Cross-origin attackers could exploit this gap to perform destructive mutations or leak restricted data on beha
When multiple CORS origins are configured, the application erroneously defaults to a wildcard ('*') instead of dynamically reflecting valid request origins. This misconfiguration silently disables cross-origin restrictions, exposing APIs. Reflect the 'Origin' request header against the allowed list of origins instead.
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
