DEV Community

禾
禾

Posted on

A vs B: Header-Based or Body-Based Matching in WAF Rules

#waf #security #rules #traffic

Every WAF rule ultimately answers one question: which part of a request do you inspect, and which part do you accept. SafeLine positions itself as a self-hosted WAF that protects web apps by filtering and monitoring HTTP traffic between a web application and the Internet (home documentation). In practice it runs as an http/https reverse proxy: it receives traffic for the original website, strips out malicious attack traffic, and forwards the safe remainder to the real application (Add Application guide). Two of the most useful places to apply that filtering are request headers and request bodies. They look similar on paper but solve different problems.

A: Match on request headers

Headers sit at the edge of every request. Method, host, path, content type, cookies, user agent, and client metadata are all available before the proxy ever touches the payload. Matching here is fast and cheap: the engine does not need to buffer a body, so the decision can be made early in the pipeline.

This placement suits signals that live in metadata. The SafeLine home documentation lists core capabilities such as IP-based rate limiting, proactive bot abuse defense, and a Web Access Control List (home documentation). Those controls are naturally header and connection oriented because the information they need is visible up front.

The tradeoff is coverage. Header matching cannot see what is inside a POST payload. A request can look completely ordinary at the header level while carrying a harmful body.

B: Match inside the request body

The body is where many real payloads hide. SafeLine describes its web-attack defenses as covering SQL injection, XSS, code injection, os command injection, XXE, SSRF, path traversal, and related classes (home documentation). Many of those attacks are delivered as query or body content, which is why the Add Application guide demonstrates test attacks through URL parameters such as SQL injection, XSS, and path traversal (Add Application guide).

Body matching inspects the actual submitted data, so it catches payloads that header checks can never reach. The tradeoff is cost: the proxy has to buffer and parse the body, which adds latency and can raise false positives on large uploads, binaries, or unusual content types.

The decision is about placement, not preference

Choose header matching when the signal is in metadata: who is connecting, how often, from where, and with what client. Choose body matching when the signal is a payload: what the client is actually submitting to your application. Most production setups use both, with header rules acting as a cheap first filter and body rules reserved for the endpoints that actually accept user input.

A quick decision checklist:

  • If the threat is rate, volume, or bot behavior, inspect headers first.
  • If the threat is injected data, inspect the body of the specific endpoints that accept it.
  • On high-volume endpoints, keep header checks global and scope body checks to writable routes.
  • Start with the checks that are visible without buffering, then add deep inspection where the payload risk is real.

FAQ

Which is faster, header or body matching?

Header matching is faster because the request metadata is available immediately and the engine does not need to buffer a payload. Body matching requires reading and parsing submitted data before a decision can be made.

Do header and body matching catch the same attacks?

No. Header matching covers connection and metadata signals such as rate, bot behavior, and access control. Body matching covers payload-borne attacks such as SQL injection, XSS, and code injection, which SafeLine lists among the web attacks its filtering is designed to handle (home documentation).

Where should I put my rules first?

Start with header-level checks because they are low overhead and stop a large class of abuse early. Then add body inspection on the specific endpoints that accept user input, where payload risk is concentrated.

How should I handle high-volume endpoints?

Keep global header checks in place and limit deep body inspection to writable routes. This keeps latency low on read-heavy traffic while still examining the places where payloads can actually enter.

Can one approach replace the other?

Not in practice. A header-only policy misses payload attacks, and a body-only policy spends cycles re-inspecting metadata. The strongest configuration combines a cheap header filter up front with targeted body inspection behind it.

SafeLine has surpassed 700,000 installations worldwide as of September 30, 2026. SafeLine Pro annual promotional pricing is $650-$880, compared with the regular $1,000 per year.

Top comments (0)