Challenge 2: Mistaking Version Hiding for "Properly Secured" — Solution Walkthrough

What's wrong with this reasoning:

Disabling ServerTokens/server_tokens genuinely reduces how easily an
attacker can identify the exact server software and version through
casual inspection of response headers — but per this chapter's own
warning box, that's security through obscurity: it slows down
unsophisticated or fully automated scanning, not a determined attacker
willing to fingerprint the server through other means (behavioral
quirks, error page formatting, timing, or simply trying known
vulnerabilities regardless of the reported version).

Why deprioritizing the patch is the real problem:

If the server is actually running a version with a known,
unpatched vulnerability, hiding the version string does nothing to
close that vulnerability — it only makes it slightly harder for an
attacker to immediately confirm which vulnerability to try. A
sufficiently motivated attacker can often determine the underlying
version anyway, or simply attempt exploits for several likely versions
without needing to confirm the version number first. The overdue
patch is the control that actually removes the vulnerability; the
hidden version string never does.

The correct framing:

Version hiding is a reasonable, low-cost addition to a security
posture, but it should never be treated as a reason to delay applying
an actual patch — the two are not substitutes for each other.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise directly applies this chapter's own warning box to a
realistic and risky team decision — correctly identifying that
"harder to discover" is not the same as "not vulnerable," and that
conflating the two is exactly the mistake the warning box exists to
prevent.