Azure Web Application Firewall - Simply Explained

Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. What Azure Web Application Firewall actually does? Azure Web Application Firewall is not the firewall you are picturing. A firewall mostly watches where traffic is going. While this one reads what the traffic says. That difference is the whole reason it exists, and it's where almost every beginner gets it wrong. Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. By the end of this episode, you will know what it catches, where it lives in Azure and the one place it doesn't protect you at all. Why a website needs its own firewall. Start with the plain definition. A web application firewall reads the requests that arrive at a website and blocks the ones that match patterns of known attacks. Microsoft calls this centralized protection, and the word centralized is doing a lot of work here. These attacks are easier to understand with an example, picture a login page with a username box, and someone types a string of database commands into that box instead of a name. That attack is called SQL injection, and it's one of the two Microsoft names is most common. Now imagine a comment box on a blog where a visitor pastes a small piece of code that then runs inside the browser of everyone who reads the page. That one is cross-site scripting. Both attacks share the same shape. Your app takes input from a stranger and trusts it more than it should. You might wonder why this isn't simply fixed inside the application code. You can fix it there, and you should. But Microsoft points out that doing it properly means constant patching and monitoring across every layer of the application. A single guard that reads requests can fix one known weakness once, and that fix then covers everything sitting behind it. The patterns themselves aren't a Microsoft invention. They come from the Owasp Core Ruleset, a public catalog that security researchers maintain and keep current as attackers change their methods, one limit shows up right away. Owasp ranks Broken Access control as the number one web risk, and ninety four percent of the applications it tested had some form of it. A web application firewall can't fix that one, because broken access control is a logic problem in your own code, and not a pattern in the request. Hold that thought because it comes back later. Where Azure Web Application firewall actually lives. This part surprises people. You don't buy Azure Web Application Firewall on its own and switch it on. It arrives as a policy that you attach to a service already handling your web traffic. Microsoft lists four places it can live. The two that matter for most people are Azure Application Gateway and Azure Front Door. The other two are Application Gateway for Containers and Azure Content Delivery Network, and the CDN option is still in preview. Application gateway is the regional choice. It sits inside the Azure region where your app runs, and it inspects traffic after that, traffic reaches you. One gateway can put as many as forty websites behind a single firewall. Azure front door is the global choice. It inspects traffic out at the edge of Microsoft's network before the request ever travels to your app. Microsoft's design guide puts front door at more than one hundred and ninety edge locations around the world. The rule of thumb is simple enough to remember if your app lives in one region. Application gateway keeps things close and simple. If your app serves people across the planet, front door stops bad requests near the person sending them instead of dragging them across the network first. The practical part is this if you already use Application Gateway to load balance a website, adding the firewall changes or service you're paying for Anyway, if you already use front door to speed up a global app, the same idea applies. You aren't standing up a new product so much as turning on a stronger setting. There's one buying detail worth knowing. Early front door comes in a standard tier and a premium tier, and the managed rule sets and bot protection only come with premium. If you buy standard expecting the full protection, you won't get it. Some teams use both at once. Front door handles the global picture at the edge, while Application Gateway applies tighter rules closer to the workload. The next question is the one that decides everything, and it's how the firewall knows what to block on how the rules decide what to block. A web application firewall runs on rules, and there are two kinds. Custom rules are ones you write yourself for your own app. Managed rule sets are ones Microsoft maintains and updates for you when both exist, your custom rules run first. The managed sets trace back to that Owasp core rule set, and they come in versions. The recommended set for anything new is Rs two point two, which builds on Owasp, CRS three point three four and adds Microsoft's own threat intelligence on top. You will still run into older names like CRS three point two and DRS two point one in existing setups. The idea that makes the whole thing click is worth slowing down for a match doesn't automatically mean a block. Each rule that matches adds points to a score, and the points depend on how serious the rule is. A critical match adds five. An error adds for a warning. Adds three and a notice adds two. The block threshold is five, so the firewall isn't really answering yes or no. It's keeping score and the score decides. Read that arithmetic again, because it decides what happens in practice. One critical match is enough on its own to block a request. One warning match at three points isn't, and the request sails through. That design is deliberate, and it exists to cut down on false alarms from a single weak signal. Custom rules work a little differently. Each one carries a priority number, and a lower number means it's checked earlier. Each rule ends in one of three actions allow it, block it, or just log it and keep going. The list of what it catches is long. It covers SQL injection, cross-site scripting command injection request smuggling response splitting, remote file inclusion protocol violations, and the scanners that sweep the internet looking for weak sites. It can even read inside Json and XML request bodies up to one hundred and twenty eight kilobytes, which matters for modern apps that talk in data rather than in forms. The scoring model is also where the tuning story begins. Because a score of five is a low bar in a busy app. A single rule that's a little too eager can push legitimate requests over the line. That's exactly why Microsoft doesn't tell you to switch on blocking from day one, and it leads straight into the next part detection mode, prevention mode, and the tuning window. Every firewall policy runs in one of two modes, and the difference is enormous. Detection mode watches traffic and writes down what it would have blocked, but it lets everything through. Prevention mode blocks the request, and the visitor on the other end gets a four hundred and three unauthorized page. Microsoft is blunt about which one belongs in production. Their guidance says to always run production workloads in prevention mode, because detection mode provides no protection at all. It only logs a site left in detection mode, has a guard who writes a very tidy report and then lets everyone walk through. The twist is that the recommended way to reach prevention is to start in detection. Anyway. You turn the firewall on, leave it watching, and then read the logs to see what it wanted to block. If it wanted to block a legitimate customer doing something normal, you have found a false positive and you fix it before the firewall ever enforces anything. That fix has a name. It's called an exclusion, and it tells the firewall to skip one specific piece of a request while still checking the rest. Microsoft's own example is worth remembering because it's very Microsoft authentication. Tokens inserted by Active Directory and password fields often look suspicious to a pattern reader, so they're common candidates for an exclusion. The timing people use is roughly one to two weeks of clean logs before switching to prevention. After that, tuning doesn't stop. New app changes and new API endpoints bring new patterns, and some of them will trip rules that were fine last month. Treat the firewall as something you keep an eye on instead of a switch you flip once. This is the part that scares beginners and the fear is reasonable. Nobody wants to be the person who turned on a security setting and took down the company website on a Friday afternoon. Detection mode exists, so you can be wrong about your rules in private before your own users feel it. None of this covers traffic that isn't an attack at all, though, like a flood of perfectly valid requests. That one is a different problem, and it deserves its own honest answer. Bots, floods and what this tool cannot do. Not all bad traffic is an attack in the classic sense. Much of that traffic is. Bots and bots come in flavors. As your wife ships a bot manager ruleset that sorts traffic into bad bots, good bots like verified search engines and unknown bots. Microsoft updates those signatures over time. The default behavior blocks the malicious ones, allows the verified search engine crawlers, and logs the unknown ones. So you can decide. Then there's volume. A flood can be made of perfectly valid requests, and no single one of them looks like an attack. The answer there is rate limiting, which caps how many requests one client can send in a window of time. Front door counts per client address over a fixed window of one or five minutes. Application gateway uses a sliding window instead, and it can group those counts by client address or by country. The catch is that rate limits have to be sized from your own traffic. Set them too low and you throttle your own users during a busy hour, which is its own kind of outage. Microsoft suggests picking a threshold above the ninety ninth percentile of your normal traffic, rather than at your all time peak. There's a softer option than blocking. An invisible JavaScript challenge quietly checks whether a visitor is a real browser or automation, and it does it without the person noticing. Capture is the visible cousin, and it's meant for the flows that matter, like sign in, sign up, and checkout. There are three honest limits worth naming. The first is that a web application firewall isn't DDoS protection. Microsoft draws this line clearly. Azure DDoS protection handles the big network layer floods, while the firewall handles application layer attacks like HTTP floods. Front door gets platform DDoS protection by default, and Application Gateway public IP needs the separate paid DDoS service, and without it, your perfectly tuned rules can still be knocked over. A second limit is the one from earlier. No firewall can patch broken access control, which Owasp puts at the top of its risk list. If the app lets the wrong person see the wrong record, no patent reader will catch that for you. The easiest one to forget is the third if you put front door in front of your app but leave the app's origin address reachable, an attacker can simply skip front door and go straight to the source. The protection only counts if you secure the origin behind it. What Azure Web application firewall costs? This is the practical question, so let's put some real numbers on it. The pricing depends on which platform you attach the firewall to, and the two platforms are built in different shapes. On Application Gateway, you pay by the hour that the gateway runs, plus a charge for capacity units, which measure the work it does. Microsoft's published example for the central US region works out to about forty four cents per gateway hour, plus about one and a half cents per capacity unit hour. The good news buried in the pricing page is that the firewall policy and the rules come included at no extra charge on Azure front door, the picture is simpler w I f pricing is folded into the front door premium tier, so you aren't paying a separate line for the firewall. That's also a reminder of the tier point from earlier, since premium is where the managed rules and bot protection live, there's an older model worth knowing if you read about it. Used by Front Door Classic and Azure CDN from Microsoft Classic, that one was pay per piece, five dollars per policy per month. A managed rule set ran twenty dollars a month, plus a dollar per million requests, and custom rules ran a dollar per rule per month plus sixty cents per million requests. Here is how to read those numbers. Every one of those figures is an example published for one region in one currency and as your prices change over time, outbound data transfer is billed separately on top of all of it. Treat the numbers as a way to understand the shape of the bill, rather than a quote you can take to your finance team. The shape is the point you're paying to keep this running hour after hour. Whether or not anything attacks you that day. That makes it easy to justify when something real depends on it, and harder when it's a weekend project nobody visits. One quick note for anyone already paying for Azure Firewall, that's a different service with a different job, and the two don't cover for each other. Watching the WAF do its job. A firewall you can't see is a firewall you can't trust, so this part matters more than it sounds. Azure WAF can send its logs to a storage account, to an event hub, or to log analytics. Every alert is written out as structured data. You can search from there. The usual Azure Tools plug in Azure Monitor collects the logs, and Microsoft Defender for cloud folds the findings into a wider view of your security posture. Microsoft Sentinel can pull the events into a security operations workflow. There's even a ready made workbook that shows matched rules, blocked rules, and overall activity. It works across application gateway, front door and the CDN option. The everyday experience is worth describing because it's the moment the tool stops being abstract. You open the log on a normal Tuesday and you see that something tried a known attack against your site at two in the morning. You also see that the request never reached your app. Nothing changed for your users and you would never have known it happened if you hadn't looked. You don't need to read every line. The habit that pays off is checking in after a launch or a busy week. That's when new patterns show up and the log is where you first hear about them. The workbook is the friendlier entry point. If raw logs feel like too much. It turns the same data into a few charts you can scan without writing a query. One caution for beginners those logs can contain pieces of actual request data if the app handles anything sensitive. Set up scrubbing rules to mask the fields you don't want sitting in a log store. Where this fits in your Microsoft three hundred sixty five world. Here comes the head fake, and it's the one that trips up almost everyone. Azure Web Application Firewall doesn't protect your Microsoft three. Sixty five tenant. It can't. And it isn't meant to. Think about what that means for a second SharePoint online teams exchange online and the rest of Microsoft three hundred sixty five are services Microsoft runs and Microsoft secures. You never attach a firewall policy to them, and you never need to. When Microsoft lists the services that Azure WAF works with, Microsoft three hundred sixty five isn't on that list, and that omission is the point. So the thing it protects is the apps you host and expose yourself. If you build a small web app, a public form, or an internal tool and put it on the internet in Azure, that's the app this firewall stands in front of. You might think of Azure WAF as the shield over your whole Microsoft world, but it's actually the lock on the one door you built yourself. It helps to line up the Azure security tools because they sit side by side rather than on top of each other. As your web application firewall reads web requests at the application layer, which is where the actual words of a request live. Azure Firewall watches network traffic across more layers, looking at addresses, ports, and protocols. Azure DDoS protection absorbs the floods so each tool covers what the others can't see. There's one compliance detail worth sharing with you. Microsoft describes Azure WAF as PCI compliant, and the PCI standard requires a web application firewall in front of any app that takes card payments. If you ever build something that handles a checkout, that requirement lands on you. The mistakes show up again and again. And there. Ordinary people leave the firewall in detection mode and believe they're protected. Others switch to blocking without tuning first, or buy front door standard and expect the managed rules, and plenty forget to lock down the origin, which quietly undoes the whole setup. The short version and one question for you. Let's pull it together in a few lines. Azure Web Application Firewall reads the requests hitting a web app you host and blocks the ones that match known attack patterns. It lives on Application Gateway for one region or on front door for many. It starts in a watch only mode before it blocks anything, and it's neither DDoS protection nor a shield for your Microsoft three. Sixty five tenant. The one idea worth keeping is the difference between checking where traffic goes and reading what it says, because that single distinction explains everything else we cover today. So here's the question I want to leave you with. What is one app you have built or want to build that would actually sit behind something like this if this made the topic feel less intimidating? Subscribe to M365 FM. To master the tools and the mindset shaping the future of work.