On this page
Atomicorp WAF Rule 345491
Rule Summary
- Rule ID: 345491
- Status: Active
- Alert message: Possible CSRF Attack - Critical Score
- Observed CWEs: None documented
- Reviewed CWE mapping: CWE-352 (Cross-Site Request Forgery (CSRF))
- Rule severity: Critical (2)
- Phase: 1 (request headers)
- Rule action: pass
- Public tags: ASL/CSRF
- Logging: log, auditlog
Description
Rule 345491 is the strongest detection-only event from Atomicorp’s scored Cross-Site Request Forgery (CSRF) detector. It is generated when the transaction score reaches 10 or greater while CSRF enforcement is not enabled. Multiple browser-provenance, source-authority, cookie, or ambient-credential signals are strongly consistent with an authenticated or state-bearing browser making a state-changing request from an unexpected context. This rule logs the request but does not deny it. Another rule may independently block the same transaction.
The request method only enables evaluation; POST, PUT, PATCH, and DELETE are not attacks merely because of the method. Missing browser provenance does not add to the score.
Troubleshooting
Review the request URI and method and the score, fetch_site, origin, origin_authority, referer, referer_authority, cookies, and credentials event fields. Determine what application action was attempted, whether the source is expected for that endpoint, whether an authenticated session was involved, whether the endpoint is intentionally cross-origin, and whether the operation succeeded.
Legitimate examples include SAML ACS and OIDC form_post callbacks, payment-provider browser returns, and purpose-built cross-origin APIs. These endpoints must retain their application- or protocol-specific validation.
False Positives
Legitimate cross-origin workflows can intentionally resemble CSRF. If the transaction is expected, configure a narrow local endpoint exemption. If the traffic should not meet the documented conditions, report it to Atomicorp Support as a possible false positive. If the source is not expected, investigate the request and associated user session.
Tuning Guidance
Do not edit 70_asl_csrf_experimental_v2.conf or any other Atomicorp-managed rule file. Put application-specific exclusions and tuning in customer-owned local ModSecurity configuration using an unused local rule ID in the 1-99999 range.
For an intentional endpoint, use an earlier phase-1 local rule to set TX:ASL_CSRF_EXEMPT=1, scoped by Host and path where possible:
SecRule REQUEST_URI "@beginsWith /saml/acs" \
"id:91001,phase:1,pass,nolog,noauditlog,t:none,setvar:tx.asl_csrf_exempt=1"
The local rule must execute before the CSRF ruleset. Applications with a custom session cookie may similarly set TX:ASL_CSRF_AUTHENTICATED=1 and TX:ASL_CSRF_CREDENTIAL_STATUS=local-session-cookie; this improves confidence and is not a bypass. After reviewing detection-only events and adding legitimate exemptions, enforcement can be enabled with an earlier local rule setting TX:ASL_CSRF_ENFORCE=1. Standard SecRuleRemoveById tuning is separate and should be used only when a global rule-level change is intended.
Configuration Notes
- Effective condition:
TX:ASL_CSRF_ENFORCE != 1andTX:ASL_CSRF_SCORE >= 10. - Action: pass; phase 1; logged and audit logged; no HTTP denial status is set.
- Rule 345491 is not a fallback when enforcement is enabled. With enforcement enabled, a score of 10 or greater is handled by rule 345490.
- Safe methods are skipped unless an earlier local profile marks a known state-changing operation with
TX:ASL_CSRF_UNSAFE_METHOD=1.
Additional Information
Score model
| Signal | Score |
|---|---|
Sec-Fetch-Site: cross-site | +5 |
Sec-Fetch-Site: same-site | +1 |
| Multiple, null, malformed, or Host-mismatched Origin | +3 |
| Multiple, malformed, or Host-mismatched Referer when Origin is absent | +3 |
| Cookies present | +1 |
| Recognized session cookie or ambient Basic, Digest, Negotiate, or NTLM authentication | +2 |
| No usable Fetch Metadata, Origin, or Referer | +0; telemetry only |
Origin takes precedence over Referer. Scheme differences are ignored and default ports are normalized during authority comparison. Cookies are weak evidence rather than proof of authentication. Bearer tokens are excluded from built-in ambient authentication, and a CSRF token or header is not automatically trusted.
Event fields
score is the final risk score; method is the HTTP method; host is the routed target authority; fetch_site is the validated Fetch Metadata value; provenance describes availability of usable provenance; origin and referer report parsing or comparison results; their _authority fields contain normalized authorities; cookies reports cookie presence; and credentials identifies recognized ambient state such as session-cookie or http-auth.
Worked example
cross-site browser request +5
Origin authority mismatch +3
cookies present +1
recognized session/ambient authentication +2
---
score 11
This is highly consistent with CSRF against an authenticated session, but rule 345491 only recorded the event because enforcement was not enabled.
Similar Rules
345490 is the enforcement event. 345492 records scores 8-9. 345493 records scores 5-7.
Outside References
- Atomicorp ModSecurity guidance
- Atomicorp rule tuning guidance
- W3C Fetch Metadata (opens in a new tab)
- OWASP CSRF Prevention Cheat Sheet (opens in a new tab)
Selected Related CVEs
This is a selected list of documented research observations, not an exhaustive coverage matrix. Absence of a CVE does not imply absence of protection.
No selected related public CVE research notes are currently published.
Reviewed CWE Mapping
These are explicit, human-reviewed mappings of this rule’s documented detection purpose. They are distinct from Observed CWEs derived from published CVE test evidence.
| CWE | Mapping basis | Confidence | Verified |
|---|---|---|---|
| CWE-352: Cross-Site Request Forgery (CSRF) | The rule's documented purpose is detecting critical-score cross-site request forgery activity. | high | 2026-08-09 |