A WAF rule blocking one payload stands in for an unshipped fix — what has it changed about the bug, and what does keeping it cost?
answer
- reachability, not correctness
- the defect is untouched
- only through this one position
- urgency drains once alerts stop
- no owner, no test, no expiry
basics
~20 sA stopgap WAF rule changes nothing about the bug. The code is still vulnerable; only requests matching that pattern, arriving through that proxy, are stopped. It costs a permanent rule nobody owns and a fix that stops feeling urgent.
solid answer
~50 sIt changes reachability, not correctness. The defect is still in the application; the rule only refuses one shape of request on one route as it passes the reverse proxy. Anything that reaches the origin another way — a second virtual host, a partner integrating straight to the backend, an internal caller, a path the proxy does not front — still meets the unfixed code. The running cost is twofold. First, the alert traffic stops, so the ticket asking the vendor to fix the code loses its urgency and the stopgap quietly becomes the control. Second, the rule accrues no owner, no test and no expiry, so in two years nobody can say what it covers or dares remove it. On day one it should carry a rule ID, a link to the incident and the fix ticket, a named owner and a review date.
go deeper
Be ready to say plainly that the code is still vulnerable and only one route through one proxy is covered. Name the bookkeeping a stopgap rule needs on day one: owner, ticket, review date.
Explain why the rule is a property of a network position rather than of the software, and list the paths that bypass it. Explain how blocking the traffic removes the pressure to fix the code.
Show you set the deletion criterion at the moment you write the rule, and that you archive the request sample. An interviewer wants to hear you refuse to let a stopgap silently become the control.
Own the framing given to the business: exposure narrowed, not defect removed. Decide who funds the fix, who accepts the residual risk, and what date that acceptance expires.
## What a stopgap rule is An application has a bug you cannot fix — the code belongs to a supplier, or the release train is weeks out. So you write a rule at the WAF in front of it that refuses requests carrying the payload seen in the incident, pinned to one parameter on one route. The industry name for this is a **virtual patch**: it stands in for the patch until the patch exists. The first thing to be exact about is the direction of the claim. The rule proves that **requests matching that pattern, on that route, through that proxy, are rejected**. It proves nothing about the application. The vulnerable line of code is untouched; if the request arrives by any path the proxy does not sit on, the outcome is identical to the day of the incident. ## What it changes, and what it does not | | Before the rule | After the rule | |---|---|---| | The defect in the code | present | present | | Requests on that route through the proxy | reach the bug | rejected | | Requests to the origin by another path | reach the bug | reach the bug | | A differently-spelled request | reaches the bug | usually reaches the bug | The paths that miss the proxy are the ones people forget: a second virtual host that resolves to the same origin, a health-check or admin listener, a partner who was given the origin address years ago to avoid a latency hop, an internal service calling the same handler, a batch integration over a channel the WAF never sees. The rule is a property of one position in the network, not of the software. ## The two prices you start paying immediately **The fix loses its urgency.** This is the failure this leaf exists for. The moment the exploitation stops showing up in logs, the pressure on whoever owns the code drops to zero. On a partner extranet where you can only *request* a fix and not make one, the stopgap becomes the permanent control by default, and nobody decided that. **The rule accrues no owner.** A rule written under incident pressure is written fast: a pattern, a route, blocking mode, done. Two years later the author has moved on, the incident write-up is in a wiki nobody reads, and the rule is one line in a policy attached to a legacy virtual host. It is now undeletable — not because anyone believes it is load-bearing, but because nobody can demonstrate it is not, and the person who deletes it owns the outage or the breach. ## What you owe the rule on day one The cheap discipline is bookkeeping written at the moment the rule ships, when the context is still in your head: - a **rule ID** and a comment naming the incident and the ticket for the code fix; - the **exact route and parameter** it guards and the archived request sample it was built from; - a **named owner** — a person or a team, not the queue; - a **review date**, because a rule with no expiry never gets looked at again; - the **test that would prove it redundant**: what the application itself must do to the archived sample once the fix ships. That last item is the one teams skip, and it is the one that decides whether the rule can ever be retired. Without a stored sample of the request and a statement of what "fixed" would look like at request level, the burden of proof for deletion can never be paid. ## The honest way to describe it to the business Say it as a change in exposure, not a change in state: *"the bug is unfixed; we have narrowed who can reach it through one door, and we are paying a rule for it until the vendor ships."* Anyone who hears "the WAF handles it" has been told something false, and it is that sentence which turns a two-week stopgap into a five-year one.
- The supplier says the WAF blocks it, so the code fix can wait. What do you say back?That the WAF blocks one spelling of one request through one proxy, and that the bug is still reachable by any caller that does not traverse it — a direct origin integration, a second virtual host, an internal client. The rule buys scheduling room, not safety, and it expires when the fix ships or when someone accepts the risk in writing with a date on it.
- Which requests does a rule on the extranet's reverse proxy never see at all?Anything that does not pass through it: traffic to the origin address directly, other virtual hosts or listeners fronting the same application, service-to-service calls inside the estate, batch or file-based integrations, and anything on a protocol the proxy does not terminate. Retiring a stopgap starts with an inventory of those paths, because they were exposed the whole time.
- What do you write down on the day the rule ships so it can ever be removed?The rule ID, the incident and the fix ticket, the route and parameter it is pinned to, an archived copy of the request sample it was built from, a named owner, a review date, and one sentence stating what the application itself would have to do to that sample for the rule to be redundant. That last sentence is the deletion criterion, and it is unrecoverable later.
It is a plank nailed over a broken window. The window is still broken, the plank only covers the side of the house you nailed it to, and the longer it holds the less anyone wants to pay a glazier.
saying these in an interview costs you the question
- Says the WAF fixed the vulnerability
- Assumes every request reaches the application through the proxy
- Treats the rule as permanent once it stops the alerts
- Cannot state what would make the rule removable
- Ships the rule with no owner, ticket link or review date