Don't Hide Vulnerabilities Behind a Firewall

A few years ago I sat in a room with a company that ran several e-commerce apps. Users could upload images, and the apps never checked the size or type of what came in. I showed them the hole and asked for a code fix. Management had a different answer: put it behind the firewall and move on.

I understand why that answer is tempting. A fix costs developer time. A firewall rule costs an afternoon. But the two are not the same thing, and treating them as the same is how companies carry serious bugs for years without knowing it.

What a firewall actually does

A web application firewall reads incoming requests and blocks the ones that match patterns it recognizes as bad. That is genuinely useful. It catches noise, known exploits, and lazy attackers. But look closely at what it is doing. It is matching patterns. It is not understanding your code, and it is not repairing anything. The vulnerable line is exactly as vulnerable as it was. The firewall is just hoping the attacker phrases the attack in a shape it has seen before.

That hope fails in three ordinary ways.

Attackers change the pattern. A filter blocks what it knows. Change the encoding, change the casing, split the payload across two fields, and the same attack walks through wearing a different coat. That is not theoretical: it is exactly how the PHP bug that gave away Windows servers worked, a single unexpected character that the guard was not looking for.

The firewall sees traffic, not intent. Take that upload bug. An oversized image is a perfectly legal-looking upload. Nothing in the request matches a known attack string. The firewall waves it through, the server tries to process a huge file, and the site falls over. A denial of service through the front door, with the firewall watching it happen.

The firewall is one more thing that can be skipped. It protects the path that runs through it. The day traffic reaches the app another way, an internal network, a forgotten subdomain, a direct hit on the server’s IP, the firewall is not in the path at all, and the hole no one fixed is wide open.

The cost you do not see

Here is the part that makes this worse than just leaving a bug open. Hiding a vulnerability behind a firewall tells everyone it is handled. The ticket closes. The developers move on. The risk register says “mitigated.” The problem is now invisible to the exact people who could fix it.

Six months later a new hire ships a feature on the same code. Or someone tunes the firewall rule to stop a false alarm. Or the app moves and the rule does not follow. The bug that everyone believed was gone is live again, and now nobody is even looking, because the record says it was dealt with. A firewall buys you time. Teams that mistake it for a fix spend that time forgetting the problem exists.

The right order

A firewall is a layer, not a lane. Fix the code first: validate the size and type of every upload on the server, and reject what you cannot safely handle. Then keep the firewall in front as defense in depth, there to buy time against the next unknown bug, not to excuse the known one.

None of this is new. Defense in depth has always meant layers that each do their own job, not one layer standing in for another. A firewall that hides a bug is not a layer of defense. It is a layer of paperwork.

So when someone tells you a vulnerability is handled, ask the plain question: if this control were removed tomorrow, is the hole still there? If the answer is yes, it was not fixed. It was hidden. And the people who most need to know it is still open are the ones the firewall just reassured.