Web Application Firewalls Explained

Joining us on this episode of Tech for Business are Michael Collins, Principal Consulting Solutions Architect at Barracuda, and Nate, CIT’s Director of Cybersecurity. They sat down to unpack Web Application Firewalls — a layer of protection most business leaders have never had to think about, until now. The conversation grew out of a trend Nate kept running into: the rise of “vibe coded” applications, built fast with generative AI and pushed live without any real security review behind them. With a growing share of those apps found to carry real vulnerabilities, Michael and Nate break down what a WAF actually does, why it matters more than ever, and how to put one in place without disrupting the people who rely on your site every day.

The Gate Agent Checks Your ID. The WAF Checks What’s in the Bag.

Michael opened with the analogy Barracuda uses to explain where a WAF fits: think of your network firewall — the Cisco, the SonicWall, the Meraki most businesses already have — as the airport agent checking your boarding pass and ID. It confirms the connection is authorized, based on IP address and port, and lets it through.

But your carry-on still goes through the scanner. That’s the WAF.

A network firewall does its work at layer 3 and 4 — the network and transport layers. A WAF specializes in layer 7, the application layer, inspecting the actual payload of HTTP and HTTPS traffic. Michael’s example: someone hits a login page and tries an injection attack to get the server to let them in when it shouldn’t. A network firewall sees an authorized connection on port 443 and waves it through. A WAF reads what’s actually inside that request and blocks it before it reaches anything.

And “application” is broader than most people assume. It’s not just your website. It’s the API behind the Starbucks app on your phone, a business-to-consumer portal, anything talking to a back-end server over a web request — whether a human ever sees it in a browser or not.

Vibe Coding Skipped the Security Review. The Numbers Prove It.

Nate named the real reason this episode exists: the rise of AI-generated applications built without any formal security process behind them.

“Vibe coding” made it possible for someone with no cybersecurity background to generate a working application and put it on the public internet, without ever checking it against the OWASP Top 10 — the standard list of common web vulnerabilities like injection attacks, cross-site request forgery, or session token theft. The application works. It solves a problem. It also, often unknowingly, introduces new risk to the business the moment it goes live.

Michael admitted he’s done the same thing himself — vibe-coded tools for interacting with Barracuda’s own WAF-as-a-Service APIs. His fix: he put those tools behind a WAF, and added a client certificate requirement on top, so nobody gets in the front door without one. His point was direct — you don’t have to become the coding security expert yourself. A WAF is the validation layer that catches what the vibe-coded app never checked for in the first place.

Not Every Website Needs the Same Lock on the Door

Michael was clear that application security isn’t one-size-fits-all. A basic municipal website with informational content only doesn’t carry the same risk as a patient portal for a clinic, a hospital, or a bank’s customer portal handling PII or PHI. The first might tolerate some downtime. The second cannot.

That’s why entry-level cloud WAFs — the kind available for around $25 a month — exist alongside enterprise-grade solutions. The cheap option covers the OWASP Top 10 basics. It won’t hold up against sophisticated bot networks or coordinated denial-of-service attacks, and it won’t give an administrator much room to fine-tune anything.

Nate gave a real example of why that fine-tuning matters — what he called the “scream test.” CIT’s own WAF, sitting in front of a site with no customer portal or sensitive data, still needed tuning once it was live. Marketing email campaigns sent out long tracking URLs that tripped a character-limit rule and got blocked, jarring the very prospects the campaign was trying to reach. A separate IP-restriction rule locked a CIT team member out of updating the website every time they logged in from a different network. Neither was an attack. Both were the WAF doing exactly what it was told, a little too literally — and exactly the kind of thing enterprise controls let you fix without giving up the protection.

Rolling Out Without Breaking Anything

The fear of disrupting real users is, according to Michael, the biggest reason organizations put off deploying a WAF. His answer is a deliberate, staged rollout, refined over nearly nine years of doing this.

Before anything goes live, he finds the person who knows the application best, points their local host file at the WAF, and has them use the site normally — click around, log in, do everything a real user would do. That gives a clean baseline: a known IP address and timeframe to check against the WAF logs, confirming what legitimate traffic actually looks like.

Only after that does the DNS cut over — and even then, the WAF stays in watch-only mode for a day or two, logging what it would have blocked without actually blocking it. Barracuda’s “Mark as False Positive” tool lets an administrator resolve any mistuned rule in a single click before blocking mode ever turns on. Once it’s live, the false positives drop off fast, and the WAF settles into something close to set-and-forget — reviewed occasionally, not babysat daily.

Sometimes there’s no time for any of that. Michael described a credit union on the West Coast running everything on-prem that got hit with a volumetric DDoS attack. Their team blocked the offending IP address in their perimeter firewall. The attacker switched IPs. The site went down again. That played out for about a week — a losing game of Whac-A-Mole — before they reached out to Barracuda. A WAF-as-a-Service trial took about fifteen minutes to spin up. The moment DNS pointed to it, the attack stopped immediately. The credit union signed the purchase order that same day.

Compliance Doesn’t Come From Installing a Box

For regulated industries — healthcare, finance, manufacturing — a WAF isn’t optional, but it’s also not a silver bullet on its own. Michael was direct about it: there’s no such thing as a “PCI-compliant WAF” or a “HIPAA-compliant WAF.” What exists is a WAF that meets the specific requirements those frameworks call for as one piece of a larger compliance picture.

Take PCI DSS: if cardholder data flows through your environment, a WAF is a required element of that cardholder data environment, but a third-party auditor still has to review the whole environment before anyone can call it compliant. Move that WAF into the cloud, and the cloud environment it runs in has to meet the same standard, because now cardholder data is flowing through infrastructure that also needs to qualify. HIPAA works the same way for PHI moving through a patient portal — the WAF is a necessary piece, not the whole answer.

Nate closed the loop with a number that’s easy to overlook: CIT’s own website — by no means a high-profile target — sees roughly 34,000 attacks a day. Most of it is automated noise: bots probing for known vulnerabilities, scanners running around the clock, the occasional legitimate security researcher. Nate compared it to looking at the ocean — chaotic everywhere, and you only ever see what’s happening at your own spot in the water. Geofencing, IP block lists, and blocking known Tor exit nodes all give a WAF a way to filter that noise at layer 3, before it ever has to inspect a single payload. None of it is visible until a WAF is actually in place to show it to you.