Skip to main content
Back to path

Welcome to a Grasp lesson

Create a free account to keep studying and create your own study path.

Lesson 80

Secure Backend API with APIM Access Restriction

Recommended resources

Hello! Welcome back.

In our last lesson, we explored how to use API Management (APIM) policies to transform requests and responses. This is a powerful feature for decoupling clients from backends. However, there's a critical security gap we left open: your backend API is still directly accessible on the internet via its own public URL. This allows clients to bypass the APIM gateway entirely, along with all the security and transformation policies you've put in place.

Today, we will close that gap. This lesson focuses on the essential security practice of locking down your backend so that it can only be reached through your APIM instance. This ensures that APIM is the single, managed entry point to your API, which is a fundamental concept for the AZ-204 exam and for building secure, production-ready systems.

1. The Need for Backend Protection

When you publish an API on a service like Azure App Service or Azure Functions, it gets a public endpoint (e.g., my-api.azurewebsites.net). If this endpoint remains open, anyone can call it directly, completely bypassing the security policies like JWT validation and rate limiting that you configured in APIM.

To truly secure your architecture, you must ensure that all traffic to your backend API is funneled through the APIM gateway.

The following short video explains this concept and why it's a critical step.

Azure API Management Deep Dive

This clip from John Savill's Technical Training channel clearly articulates the need to lock down backend APIs and prevent them from being used directly.

Watch from 00:26:45 to 00:29:13. Focus on the core message: if you want to enforce the use of APIM, you must block direct access to your backend services.

The video mentions two primary methods for this lockdown:

  1. IP-based restrictions: Configuring a firewall on the backend to only allow traffic from APIM's IP address.
  2. Authentication: Requiring a secret or certificate that only APIM possesses.

For backends hosted on Azure App Service or Azure Functions, IP-based restriction is the most direct and common method. Let's see how to implement it.

Secure Backend APIs with Azure API Management Architecture
This diagram illustrates a secure architecture where clients access backend services (like App Service and Functions) exclusively through a gateway layer, in this case, a combination of Azure Front Door and API Management. Our goal is to enforce the boundary of the virtual network, ensuring the backend APIs cannot be accessed directly from the public internet.

2. Step 1: Identify Your APIM Instance's IP Address

To create an IP restriction rule, you first need the public IP address of your APIM instance. For dedicated service tiers (Developer, Basic, Standard, Premium), each APIM instance has a static public virtual IP (VIP) address that is exclusive to it.

IP addresses of Azure API Management

This Microsoft Learn article explains where to find the IP addresses associated with your APIM instance. We'll focus on the public IP address.

Read the introduction and the section 'Public IP addresses'. This will confirm that your dedicated tier APIM instance has an exclusive, static public IP and show you how to find it.

As the article describes, you can find this IP address on the Overview blade of your APIM instance in the Azure portal.

Azure API Management Instance Public IP Address
As shown in this screenshot from the Azure portal, the public 'Virtual IP (VIP) address' of your API Management instance is displayed prominently on its Overview page. This is the IP address you will use to configure the allow-list on your backend service.

Action:

  1. Navigate to your APIM instance in the Azure portal.
  2. On the Overview page, locate the Virtual IP (VIP) address.
  3. Copy this IP address to a notepad; you will need it in the next step.

3. Step 2: Configure Access Restrictions on the Backend

Now that you have the APIM instance's IP address, you can configure your backend service to only accept requests from it. Assuming your backend is an Azure App Service or Function App, you will use a feature called Access Restrictions.

This feature acts as a simple firewall, allowing you to define a priority-ordered list of allow/deny rules. When you add your first "Allow" rule, an implicit "Deny all" rule is automatically enforced for any traffic that doesn't match.

Set up Azure App Service access restrictions

This Microsoft Learn document provides a comprehensive guide to configuring access restrictions for Azure App Service, which also applies to Azure Functions. We will use it to create our lockdown rule.

Read the introduction to understand the concept of allow/deny lists. Then, quickly review the sections 'Manage access restriction rules in the portal', 'Add an access restriction rule', and 'Set an IP address-based rule' to familiarize yourself with the process before we walk through it.

Hands-On Practice: Locking Down the Backend

Let's apply this knowledge. Follow these steps to secure the backend API you have been using throughout this course.

  1. In the Azure portal, navigate to your backend App Service (or Function App).
  2. In the left-hand menu, under Settings, select Networking.
  3. Under Inbound traffic configuration, click on Access restrictions.
  4. On the Access Restrictions page, click + Add.
  5. In the "Add Access Restriction" pane, configure the rule with the following settings:
    • Name: Allow APIM Instance
    • Priority: 100 (lower numbers are evaluated first)
    • Action: Allow
    • Type: IPv4
    • IP Address Block: Enter the IP address you copied from your APIM instance. You must add /32 to the end to specify a single IP address (e.g., 20.54.32.12/32). This is CIDR notation.
  6. Click Add rule. You will now see your rule in the list. Notice that there is an implicit deny rule in effect.
  7. Click Save at the top of the Access Restrictions page to apply the changes.

Verification

Now, let's test that the lockdown is working as expected.

  • Test 1: Direct Access (Should Fail)

    • Find the default URL of your App Service (e.g., https://my-unique-api.azurewebsites.net/weatherforecast).
    • Try to access this URL directly in your web browser or using Postman.
    • You should receive an HTTP 403 Forbidden error. This is excellent! It means the access restriction is working and blocking public traffic.

  • Test 2: Access via APIM (Should Succeed)

    • Go back to your APIM instance in the Azure portal.
    • Navigate to your API and open the Test tab for the relevant operation.
    • Send a request.
    • You should receive an HTTP 200 OK response with the expected data. This confirms that traffic from your APIM instance is correctly allowed through the firewall.

You have successfully secured your backend API!

Conclusion

In this lesson, you implemented a fundamental security pattern for API architectures on Azure. By ensuring your backend can only be called from your APIM instance, you create a secure gateway that enforces all your defined policies.

Key Takeaways:

  • Leaving a backend API's public endpoint open creates a major security vulnerability, as it allows clients to bypass your APIM gateway.
  • The most direct way to secure an Azure App Service or Function App backend is by using IP Access Restrictions.
  • This involves a two-step process:
    1. Find the static public Virtual IP (VIP) address of your dedicated-tier APIM instance.
    2. Add an Allow rule for this IP address in the backend service's networking configuration.
  • Adding the first "Allow" rule implicitly creates a "Deny all" for any traffic that doesn't match the rules you've defined.

Next Steps

We have now covered how to import, secure, transform, and lock down an API with Azure API Management. In the final lesson of this module, we will address another critical aspect of the API lifecycle: configuring versioning for an API. This will show you how to evolve your API over time without breaking existing client applications.