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.
Comparing an Origin header's parsed host against `conn.host` provides no protection against DNS rebinding attacks because both values are attacker-controlled. Validate origins against a strict allowlist or trusted localhost hostnames instead.
HTTP handler serves local MCP/RPC transport requests without validating the Host header against DNS rebinding attacks on loopback connections.
Unanchored prefix validation on HTTP Referer or URL. Using `str_starts_with($referrer, $base)` without an exact match or a trailing path separator ('/') allows attackers with domains starting with the base URL string (e.g., `https://example.com.attacker.tld`) to bypass origin checks.
Permission check evaluates permissions against the primary main frame instead of the requesting RenderFrameHost. This allows cross-origin iframes to inherit permissions intended only for the top-level main frame.
Inspecting `http.Request.RequestURI` for path prefixes or regular expressions can be bypassed using percent-encoding (e.g. `/%61pi`) or query parameters because `RequestURI` retains the raw, unparsed request line. Use `r.URL.Path` instead.
MCP HTTP transport does not validate Host or Origin headers before handling requests, which may allow DNS rebinding and cross-origin attacks against locally running servers.
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
Deleting proxy headers like 'x-forwarded-for' and injecting the raw socket IP into another header without recording the proxy presence. This destroys evidence of the proxy hop. If the application is hosted behind a local reverse proxy, downstream components may incorrectly trust external traffic as local (e.g., originating from 127.0.0.1). Evaluate or record
Calling Start() directly on an mcp-go StreamableHTTPServer starts an HTTP listener without validating Host or Origin headers, making local listeners vulnerable to DNS rebinding attacks. Wrap the handler in Host/Origin validation middleware and serve via net/http.Server instead.
Retrieving a value from gRPC incoming metadata using index `[0]` on the slice. Because incoming metadata values are controlled by the client, a forged value supplied by the client will appear first in the slice (`[0]`), masking any server-appended verified claims. To securely pass context from an authorizer interceptor, use `context.WithValue` and `ctx.Value
The request handler overrides `parse_request` but does not validate the HTTP `Host` header. Without checking the `Host` header before processing requests or authenticating clients, the server is vulnerable to DNS rebinding attacks if it is bound to localhost or an internal network. Attackers can extract data or call APIs from the local server via a victim's
Trusting the client-provided scheme without verifying the underlying secure channel state can lead to transport-state spoofing. An attacker can supply "https" via an absolute-form HTTP request or HTTP/2 `:scheme` pseudo-header over a plaintext connection to mislead security decisions.
The FastAPI application is instantiated without the `TrustedHostMiddleware`. This can expose the service to DNS rebinding attacks if it is reachable on localhost or an internal network and not situated behind a reverse proxy that actively filters the `Host` header. Consider adding `TrustedHostMiddleware` to restrict access by enforcing an allowed list of hos
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
The Starlette application configures middleware but does not include `TrustedHostMiddleware`. If the application generates sensitive URLs (like password resets) based on the incoming Host header, this could lead to Host header injection vulnerabilities.
Using a blocklist of HTTP methods (e.g., explicitly matching POST or PUT) to deny requests is prone to omissions. Methods like DELETE or PATCH may be inadvertently allowed, leading to CSRF or unintended modifications from untrusted origins. Use an allowlist of safe methods (e.g., GET, HEAD, OPTIONS) and deny all others instead.
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
Validating postMessage origins using string search methods like `includes`, `indexOf`, `startsWith`, or `endsWith` is insecure and prone to bypasses. For example, `origin.includes('trusted.com')` allows bypasses from origins like `https://trusted.com.attacker.com`. Attackers can use this to send malicious messages resulting in Cross-Site Scripting (XSS) or d
The application configures a WebSocket upgrader to bypass origin validation by unconditionally returning 'true' in 'CheckOrigin'. This exposes the WebSocket server to Cross-Site WebSocket Hijacking (CSWSH). Remove the 'CheckOrigin' field to enforce the default same-origin policy, or implement strict comparison of the 'Origin' header against a whitelist of tr
A custom server configuration misses automatic DNS rebinding protection when bound to localhost. This was specific to FastMCP's 'transport_security' handling.
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
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
