Securing Azure App Service APIs Using Azure API Management – Part 2

Overview

Welcome to Part 2 of our series on securing cloud APIs. In Part 1, we established a global perimeter using Azure Front Door to inspect, filter, and route traffic at the edge. Now, we will bring that security strategy deeper into your infrastructure. In this post, we will configure Azure API Management (APIM) as our internal gatekeeper and completely lock down the App Service origin. By completing these steps, you ensure that your Enterprise Architecture cannot be bypassed, creating an enhanced, multi-layered defense system.

Introduction

It is a common misconception that simply putting an application “behind” a firewall or a gateway automatically makes it safe. If your App Service’s default URL (such as .azurewebsites.net) remains publicly accessible, attackers can completely bypass your Front Door security and access your application directly. This renders your edge Web Application Firewall (WAF) completely useless.

To achieve a true Zero-Trust architecture, every component in your system must cryptographically or logically verify the identity of the component that calls it. You cannot rely on network obscurity. We achieve this strict chain of custody through mandatory header validation and explicit network-level IP restrictions. Let’s dive into how to effectively lock all the backdoors in your application.

Phase 2: Enforcing the Chain of Trust

Step 1: Validate Front Door inside APIM

Because Azure Front Door is a multi-tenant service, simply allowing Microsoft’s Front Door IP addresses into your APIM instance is not sufficient for security. If you only use IP filtering, another Azure customer could theoretically create their own Front Door and point it at your APIM URL. To prevent this, APIM needs to know that incoming traffic actually came from your specific Front Door profile, not just any random Front Door on the internet.

• Locate your ID: Go to your Azure Front Door overview page in the Azure portal and copy your unique Front Door ID.
• Open the Policy Editor: In APIM, navigate to your API’s inbound policy editor (you can apply this at the “All APIs” global level for maximum security).
• Enforce the Header Check: Add a <check-header> policy that specifically looks for the X-Azure-FDID header. If the header is missing or if it doesn’t perfectly match your exact ID, APIM will immediately drop the request and return a 403 Forbidden error before it wastes any backend processing power.

Here is an example of what that XML policy looks like:

XML

<check-header name=”X-Azure-FDID” failed-check-httpcode=”403″ failed-check-error-message=”Forbidden” ignore-case=”true”>

<value>your-unique-front-door-id-here</value>

</check-header>

Step 2: Correct the Host Header

Because your API traffic is passing through multiple proxies (Front Door ➔ APIM ➔ App Service), the HTTP Host header can become mismatched. Azure App Services rely on Server Name Indication (SNI) and the Host header to route traffic to the correct underlying web worker and to validate the SSL/TLS handshake. If the App Service receives a request with the APIM host name instead of its own, it will reject the connection.

• Inject the Header: In that same APIM inbound policy editor, right below your Front Door ID check, add a <set-header> rule.
• Override the Value: Override the Host header to match your App Service’s default URL (e.g., yourapp.azurewebsites.net). This ensures that when APIM forwards the request, the App Service accepts the SSL handshake natively.

Here is the XML snippet for the host override:

XML

<set-header name=”Host” exists-action=”override”>

<value>yourapp.azurewebsites.net</value>

</set-header>

Step 3: Restrict App Service Access

The final and most crucial step is making your App Service completely private from the outside world. Even with APIM configured perfectly, your App Service must be instructed to ignore the public internet.

• Find the APIM VIP: Navigate to your APIM instance’s overview page and copy its Virtual IP (VIP) address.
• Configure Networking: Go to your App Service, select the Networking blade on the left menu, and open the Access Restrictions configuration.
• Create the Allow Rule: Add a new allow rule specifically for the APIM IP address you copied. Once you add an explicit “Allow” rule, Azure’s networking stack will automatically create an implicit “Deny All” rule for everything else.

Note: Once this is applied, even your own development team will not be able to hit the App Service directly from their local machines. All testing must be routed through the Front Door URL, ensuring your security policies are applied equally to external users and internal staff.

Conclusion

This multi-layered approach ensures your data and infrastructure remain resilient against modern cyber threats.