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.
State-changing API action is executed while same-domain checks are explicitly bypassed without validating the HTTP request method or request origin, leading to CSRF.
Endpoint 'sendEmail.json.php' is included in CSRF bypass list, allowing cross-site request forgery when authenticated administrators visit malicious sites.
The 'netmount' command is omitted from $csrfProtectedCmds in elFinderConnector, allowing cross-site requests to perform network mount operations without CSRF token validation (CVE-2026-81890).
Validating REST API routes using $_SERVER['REQUEST_URI'] when handling 'rest_cookie_invalid_nonce' errors can allow CSRF protection bypass via query parameter injection.
State, CSRF token, or nonce validation function returns :ok in a fallback clause where request parameters are ignored. This allows attackers to bypass validation by omitting required request parameters. Return {:error, ...} instead.
CSRF token cookies should have HttpOnly set to true to prevent client-side script access and token exposure.
Use of legacy token-based CSRF protector detected. Token-based CSRF cookie mechanisms can be vulnerable to cross-origin token leakage or bypass. Use modern cross-origin header validation (CrossOriginProtection) instead.
Legacy cookie-based CSRF protection using `NewCSRFProtector` or `CsrfOptions` is susceptible to cross-origin bypasses. Use modern origin-based cross-site request protection (`CrossOriginProtection`) instead.
Custom cookie-based CSRF token implementation detected. Storing CSRF tokens in cookies or using double-submit cookies without strict origin checking can allow CSRF token bypasses across cross-origin boundaries. Replace cookie-backed CSRF tokens with header-based origin verification (CrossOriginProtection).
Legacy custom cookie-based CSRF protector implementation is deprecated in favor of CrossOriginProtection.
Detected custom token-based CSRF protector implementation. Custom CSRF implementations relying on cookie/token comparisons are prone to token leakage and logic bypasses. Use standard origin-checking cross-origin protection middleware (e.g., verifying Sec-Fetch-Site and Origin headers) instead.
Custom cookie-based CSRF protection implementations are prone to token leakage and validation flaws. Use standard CSRF middleware or Origin and Fetch-Metadata header validation.
Legacy custom CSRF protector interface detected. Custom cookie-based CSRF implementations are prone to CSRF bypasses; standard CrossOriginProtection middleware should be used instead.
Legacy cookie-based CSRF protection without origin verification is vulnerable to bypass.
State-changing operations registered to accept GET requests are vulnerable to Cross-Site Request Forgery (CSRF). GET requests are typically unprotected by anti-CSRF tokens and can be easily triggered by navigating to a URL or loading an image. Ensure you use POST, PUT, DELETE, or PATCH for operations that modify state on the server.
Detected a potential OAuth state validation bypass. The application advances the OAuth flow by checking simply for the presence of 'code', 'error', or 'state' parameters in the request, rather than verifying that an active session's state matches the incoming 'state' parameter. This can expose the OAuth integration to Cross-Site Request Forgery (CSRF) or ses
OAuth state parameters are parsed directly from unauthenticated base64 JSON without cryptographic signature or nonce verification. An attacker can tamper with state fields to bypass authorization checks or conduct CSRF attacks.
The getSameSite() method hardcodes a null return value, dropping the configured SameSite attribute from HTTP response cookies and leaving applications vulnerable to CSRF and cross-site cookie leaks.
A chi Router defines mutating endpoints (e.g., POST, DELETE) but lacks a CSRF protection middleware assignment natively or in a Group block. This can lead to CSRF vulnerabilities if cookie-based sessions are used.
State-changing HTTP endpoints (POST, PUT, DELETE, PATCH) should be protected against Cross-Site Request Forgery (CSRF) if they rely on cookie-based authentication. This rule detects chi routes missing a `.Use(...)` middleware application within the same function scope, which often indicates missing CSRF protection.
Destructive entity operation `$ENTITY->delete()` is called without validating the CSRF token first. This may allow cross-site request forgery (CSRF) attacks to delete resources.
Missing CSRF middleware or proper authorization scope validation on Gin router setup.
An HTTP handler creates or opens a file but lacks an explicit validation check on the request, which may lead to CSRF or missing authorization vulnerabilities if exposed without protection.
The application handles the OAuth `error` response from the callback URL before validating the `state` parameter against the expected session value. By submitting a crafted request with an `error` parameter, an attacker can bypass the state check, tricking the service into prematurely rejecting the flow and terminating it. Validate the `state` parameter unco
