Azure Firewall now supports HTTP header insertion in application rules, and this is one of those features that sounds small but opens up a lot of useful scenarios for network security teams. The feature went GA on July 27, 2026, and it lets you add or overwrite HTTP request headers directly from the firewall without changing anything on the client side.
The basic mechanism is simple: you define an application rule in Azure Firewall policy, and alongside the usual FQDN filtering, you specify which headers to inject. The firewall intercepts matching traffic and stamps the header before forwarding it to the destination. That is it. But what you can do with it is where it gets interesting.
What you can use it for
The most obvious use case is tenant restriction. If you use Microsoft Entra ID and want to enforce which tenant your users can authenticate against, you need to inject the Restrict-Access-To-Tenants header into traffic destined for login.microsoftonline.com and related endpoints. Before this feature, you had to rely on on-premises proxies or third-party network virtual appliances to do that. Now Azure Firewall can handle it natively.
Another common scenario is adding custom headers for legacy application compatibility. Some applications, especially older web apps and APIs, expect specific headers in every request. Maybe they look for a X-Forwarded-For header with a trusted IP, or they need a X-Tenant-ID to route requests internally. Without header insertion at the firewall level, you either modify the application or deploy a reverse proxy. With this feature, you can solve it in the network layer.
Security teams can also use header insertion for audit and compliance. Injecting a header like X-Source-Firewall or X-Audit-ID into all outbound traffic gives downstream systems a reliable way to identify which requests passed through the firewall, which is useful for logging and incident response.
How it compares to alternatives
Azure Front Door also supports header injection via its rules engine, but Front Door is a global load balancer and application delivery controller, not a firewall. It sits in front of your public-facing apps. Azure Firewall header insertion works for all traffic that passes through the firewall, including outbound and east-west traffic that never reaches Front Door.
The other alternative is deploying a network virtual appliance like HAProxy or F5 to strip and insert headers. That works, but it adds complexity, cost, and another thing to maintain. Doing it in Azure Firewall keeps the policy in one place and reduces the number of hops traffic has to go through. For organizations running a hub-and-spoke topology with Azure Firewall as the central egress point, this is a natural extension of the existing architecture.
Practical considerations
There are a few things to be aware of. Header insertion works at the application rule level in Azure Firewall policy, so you need to be using the Premium or Standard SKU. You configure it with either Azure PowerShell (New-AzFirewallPolicyApplicationRuleCustomHttpHeader), CLI, or ARM templates. The Azure portal support for the feature should be available, but if you need to script it across many rules, PowerShell is the cleaner path.
Header insertion happens after the firewall has already applied its other inspection rules. That matters because if the firewall drops the connection for another reason, no headers get injected. The order of operations is: DNAT rules, network rules, application rules (where headers are applied), then forwarding.
One limitation to keep in mind: you cannot inject headers into encrypted HTTPS traffic before it reaches the destination. Azure Firewall does not perform TLS interception by default. The header insertion only works for traffic the firewall can inspect at the application layer. If you need to inject headers into HTTPS traffic, you are looking at deploying a reverse proxy or using Azure Application Gateway instead.
Real-world deployment patterns
The tenant restriction use case is probably the one that will drive most adoption. Many organizations already have Conditional Access policies that check tenant IDs, but those policies only work if the header is present. Without an inline proxy or NVA doing header insertion, users on corporate networks could potentially authenticate against any Entra ID tenant, including external ones, if the firewall only does FQDN filtering. Adding header insertion to your outbound Azure Firewall rules closes that gap.
Another pattern is using header insertion for tenant isolation in multi-tenant SaaS platforms. If your application uses headers to route requests to the correct tenant backend, inserting those headers at the firewall level ensures that traffic arriving from your internal network always carries the right routing information, even if the client forgets to send it.
For DevOps teams managing Azure Firewall through infrastructure as code, header insertion adds another dimension to your firewall policies. Combining header insertion rules with Azure Policy can enforce that all new application rules include the required headers, which keeps security consistent across teams and environments.
What this means for your deployment
If you are already running Azure Firewall and managing tenant restriction through other means, this feature lets you consolidate that policy into your firewall rules. The same applies if you have been maintaining a separate proxy appliance just for header manipulation. The cost and operational overhead of that proxy can go away.
For new deployments, header insertion is worth baking into your Azure Firewall policy from the start. Even if you do not need tenant restriction right now, having the ability to tag traffic at the firewall level gives you options for audit, routing, and legacy app compatibility that you might need later. The feature is GA, so there is no preview stability risk to worry about.