Challenge 3: Why DetectionOnly Comes Before On — Solution Walkthrough

The reasoning:

The OWASP Core Rule Set is deliberately broad, designed to catch a
wide range of attack patterns across many different kinds of
applications it's never specifically seen before. That breadth comes
with a real cost: some of its rules will inevitably trip on
legitimate traffic that happens to resemble an attack pattern
superficially -- per this chapter's own example, a search box
submission containing the word "select," or a rich content field
containing HTML-like text. Enabling SecRuleEngine On immediately, with
no prior visibility into how the rule set behaves against this
specific site's own real traffic, risks blocking genuine users and
legitimate requests without any warning -- a real production outage
caused by the very tool meant to protect the site.

Why DetectionOnly fixes this:

SecRuleEngine DetectionOnly runs every rule exactly as it would in
blocking mode, logging every request that would have been blocked --
but doesn't actually block anything. This gives a real window to
review those logs against actual production traffic, identify any
rules producing false positives for this specific application, and
tune or exclude them, before ever switching to SecRuleEngine On. By
the time enforcement is actually turned on, the rule set has already
been validated against the site's own real behavior rather than
against a generic assumption of what "normal" traffic looks like.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise checks that the reader understands DetectionOnly's real
purpose -- a safe validation window against real traffic, not just a
"weaker" or "testing" mode -- and can connect it to the same
verify-before-enforcing caution this course has already applied
elsewhere, rather than treating it as an arbitrary extra step.