Azure API Management: Seven Layers of API Security

Putting Azure API Management in front of an API is a useful start. The harder question is whether every request actually passes through it. If a caller can reach the backend directly, the gateway’s policies may never run.

This guide groups an API security review into seven layers. It is a practical checklist, rather than an official Microsoft seven-layer model. The right implementation depends on your APIM tier, network design, backend, and application requirements.

The request path

Client → WAF → API Management → authenticated backend → application authorization
Send gateway and application telemetry to your monitoring platform. Test both the intended route and attempts to bypass it.

1. Protect the entry point

For an internet-facing API, consider a web application firewall upstream of APIM, such as Application Gateway. Restrict alternate entry points so that callers cannot simply skip the WAF. Choose the network controls for your deployment model; a private address alone does not establish which callers are trusted.

Start WAF tuning with representative traffic and review false positives before enforcing changes. A rule that blocks a legitimate payment request is an availability problem as well as an operational one.

2. Validate access tokens

Validate tokens at the gateway before forwarding protected requests. Check the issuer, intended audience, signature, and lifetime. For Microsoft Entra tokens, review the validate-azure-ad-token policy; validate-jwt supports more general JWT validation.

Keep the backend’s trust model explicit. If it receives the caller’s access token, it should validate that token for its own resource. If APIM uses a separate service identity, the backend must authenticate and authorize that identity. Gateway validation does not remove the need for application authorization.

3. Check permission for the operation

A valid token does not give its holder permission to do everything. Define which delegated scopes or application roles each operation requires. Then enforce those checks and the application’s resource-level rules.

For example, permission to read an account balance should not automatically allow a transfer. The application must also check that the caller is allowed to act on the specific account in the request. Test that boundary with two different test users.

4. Set limits that fit the workload

Use rate-limit-by-key where supported to apply limits to a verified caller or another appropriate key. Set thresholds from expected traffic and backend capacity, and test burst behavior.

Rate limiting helps control abuse and load; it is not a transaction-risk engine or a precise financial counter. Distributed enforcement can be approximate. Keep payment limits, fraud decisions, and idempotency checks in the relevant application services.

5. Validate request content

Use validate-content to check supported payloads against the API schema and define how invalid content is handled. Set appropriate size limits and test missing fields, unexpected properties, malformed bodies, and invalid content types.

Schema validation does not prove that an action is safe. Keep business validation and safe data access in the application. Trial changes against realistic requests before rejecting traffic in production.

6. Protect the backend connection

Authenticate APIM to the backend using a supported mechanism, such as managed identity or a client certificate. Grant only the access needed. With certificate authentication, plan rotation and confirm the backend rejects an untrusted certificate.

Combine identity controls with network restrictions. A private endpoint provides private connectivity; it does not automatically limit access to the APIM subnet. Review public access, DNS, routing, and applicable network rules, and test direct access from an unauthorized source.

7. Monitor failures and test the controls

Use Azure Monitor and diagnostic settings to observe gateway requests, response codes, latency, and failures. Correlate relevant gateway and backend events so an investigation can follow a request through the system.

Alert on meaningful changes, such as a sustained increase in denied requests or backend errors. Avoid collecting access tokens, secrets, or unnecessary request bodies. Assign an owner to each alert and test what happens when it fires.

Example: validate a delegated access token

This illustrative inbound policy fragment is for a single-tenant v2 token and an operation requiring the delegated scope Orders.Read. Replace TENANT_ID, API_AUDIENCE, and the scope with values from your application’s token contract. Application-only permissions use different claim checks. Review the effective inherited policy and test in a non-production API before deployment.

<validate-jwt header-name="Authorization" require-scheme="Bearer"
  require-expiration-time="true" require-signed-tokens="true"
  failed-validation-httpcode="401">
  <openid-config url="https://login.microsoftonline.com/TENANT_ID/v2.0/.well-known/openid-configuration" />
  <audiences><audience>API_AUDIENCE</audience></audiences>
  <issuers><issuer>https://login.microsoftonline.com/TENANT_ID/v2.0</issuer></issuers>
  <required-claims>
    <claim name="scp" match="all" separator=" ">
      <value>Orders.Read</value>
    </claim>
  </required-claims>
</validate-jwt>

This example has been checked against the policy reference, but has not been run in your Azure environment. It does not configure network restrictions, backend authentication, or object-level authorization.

A small validation example

In a test environment, send the same protected request with no token, an expired token, a token for the wrong audience, and a valid token without the required permission. Record the expected denial for each case. Then send an authorized request and confirm it succeeds. Finally, attempt the backend URL directly from a source that should not have access.

Before you go live

Confirm that alternate routes are blocked; token and permission checks fail safely; the backend authenticates its callers; limits and validation rules allow legitimate traffic; certificate or identity changes have a recovery plan; and monitoring produces an actionable signal. Repeat these tests after changes to policies, networking, or authentication.

Trade-offs to make deliberately

Each control adds configuration and operational work. WAF rules need tuning, certificates need rotation, and stricter payload validation can break older clients. Roll out changes in stages, document exceptions with an owner and expiry date, and keep a tested rollback path.

Microsoft documentation

API authentication and authorization
APIM with Application Gateway
JWT validation
Rate limits by key
Content validation
Monitoring APIs