WAF custom rule for bock others cookie and permit only a specific cookie name and value

You explained it clearly. The main thing is: don’t try to match the entire Cookie header unless you absolutely have to. Cookies are sent as a single header with multiple name=value pairs, order can change, and extra cookies are common.

How to build the rule (recommended approach)

Create two custom rules for the same path:

Rule 1 (Allow)

• Priority: higher (runs first)
• Match:
  • Request URI equals /example-path (or “begins with” depending on your need)
  • RequestCookie cookie name equals CookieName
  • Cookie value equals abc123
• Action: Allow

Rule 2 (Block all others)

• Priority: lower (runs after)
• Match:
  • Request URI equals /example-path
• Action: Block

This implements: “only allow requests to /example-path when the cookie is present with the correct value; otherwise block.”

Important: If your WAF engine doesn’t support an “Allow” action (some WAFs only support Block/Log), then do it with a single Block rule using a negation:

• Match:
  • URI equals /example-path
  • AND (CookieName is missing OR CookieName value is not abc123)
• Action: Block

Difference between the two configurations you listed

1) RequestHeaders['Cookie'] DoesNotEqual "Cookie=abc123"

This compares the entire Cookie header string to an exact value. In real traffic the header typically looks like:
Cookie: CookieName=abc123; othercookie=xyz; ...

So this will almost always misbehave because:

• multiple cookies exist
• order can change
• spacing/formatting differs
• the header value is not exactly one cookie pair

Use this only if you’re doing a “contains” style match and you fully understand the formatting risk.

2) RequestCookie name equals CookieName AND value equals abc123

This is the correct way if your WAF supports cookie parsing. It:

• extracts the specific cookie by name
• compares only its value
• ignores other cookies and header order

This is much more reliable and is the best practice.

One practical warning

Using a static cookie value like abc123 as an access control mechanism is weak unless it’s a secure, signed, short-lived token. Otherwise anyone can replay it. If this is meant as protection, consider using auth (JWT/session cookie), signed cookies, or mTLS.