API Security Design Field Guide

Security Architecture · Modern Endpoint Guides

🔌 API Security Design

API Security Design Field Guide

APIs are the #1 attack surface in modern applications. This guide covers the OWASP API Top 10, Azure API Management protection policies, OAuth 2.0 best practices, and Defender for APIs for discovering unmanaged shadow APIs.

📅 Updated: June 2025 ⏱️ 30 min read 🎯 Security Architects & IT Admins

📋 Why API Security Is Critical

According to OWASP, APIs exposed more data than any other attack vector in 2023. The three core reasons are interconnected: APIs are exposed directly to the internet, they hold critical business logic and sensitive data, and they are typically monitored far less rigorously than traditional web applications.

⚠️

Key stat: Gartner projects that by 2025, APIs will become the most frequent attack vector for enterprise web applications — making a structured API security program a business requirement, not a nice-to-have.

🌐 Direct Exposure

APIs are internet-facing by design, bypassing traditional perimeter controls.

🧠 Business Logic

APIs carry sensitive operations: payments, user data, authentication flows.

👁️ Low Visibility

Shadow APIs and undocumented endpoints are common in enterprise environments.

⚠️ OWASP API Top 10 — 2023

The OWASP API Security Top 10 defines the most critical risks for API implementations. Each maps directly to a control you can implement in Azure.

API1

Broken Object Level Authorization

Accessing another user's objects by manipulating resource IDs in the request.

API2

Broken Authentication

Weak tokens, brute force susceptibility, or exposed credentials in requests.

API3

Broken Object Property Level Auth

Returning sensitive fields that should not be exposed (mass assignment / over-exposure).

API4

Unrestricted Resource Consumption

No rate limiting allows DoS attacks and cost attacks on cloud-billed APIs.

API5

Broken Function Level Authorization

Admin-only functions accessible to regular users due to missing role checks.

API6

Unrestricted Access to Sensitive Business Flows

Ticket scalping, account enumeration, bulk discount abuse, and similar automation attacks.

💡

Azure mitigation: APIM Policies address API2, API4 directly. Entra ID roles address API5. Defender for APIs surfaces API1 and API3 violations through traffic analysis.

🛡️ Azure API Management — Policies

Azure API Management is your primary enforcement layer. Policies execute on every request before it reaches your backend — meaning you centralize security controls without touching application code.

Policy	Mitigates	Configuration Note
`rate-limit-by-key`	API4 – Rate Limiting	Limit per Subscription Key or Client IP; 100 calls/min is a safe default
`validate-jwt`	API2 – Authentication	Require valid Bearer token from Entra ID on every API call
`ip-filter`	Network restriction	Restrict access to approved IP ranges for internal APIs
`validate-content`	Injection attacks	Validate request body schema before forwarding to backend
`cors`	Cross-origin abuse	Never use wildcard — specify exact allowed origins
`quota`	API4 – Daily limits	Hard daily/monthly cap per subscription to prevent cost attacks

Implementation Steps

Configure Inbound Policy — JWT Validation

Every API behind APIM must require a valid Bearer token issued by Entra ID. This is the foundational control against unauthenticated access.

📍 APIM → APIs → [Your API] → Inbound Processing → Add validate-jwt policy with your Entra tenant's JWKS URI

Configure Rate Limiting

Apply rate-limit-by-key at 100 calls/minute per Subscription Key and a quota of 10,000 calls/day. This prevents both DoS attacks and runaway cost accumulation.

Enable Defender for APIs

Activate the Defender for APIs plan in Defender for Cloud. It discovers shadow APIs integrated with APIM and analyzes traffic for anomalies automatically.

<!-- Example: validate-jwt + rate-limit inbound policy fragment -->
<inbound>
  <validate-jwt header-name="Authorization" failed-validation-httpcode="401">
    <openid-config url="https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration"/>
    <required-claims>
      <claim name="aud" match="all">
        <value>api://your-api-app-id</value>
      </claim>
    </required-claims>
  </validate-jwt>
  <rate-limit-by-key calls="100" renewal-period="60" counter-key="@(context.Subscription.Id)"/>
</inbound>

🔑 OAuth 2.0 Best Practices

OAuth 2.0 is the foundation of modern API authentication. Using the wrong flow or token configuration is one of the most common ways APIs are compromised.

✅ Authorization Code + PKCE

The correct flow for Web and SPA applications. Never use the Implicit Flow — it's deprecated and exposes tokens in the URL fragment.

✅ Client Credentials (M2M)

Use for Service-to-Service communication. Always pair with a Managed Identity in Azure — fno secrets stored in code or config files.

🕐 Short Token Lifetimes

Access Token lifetime should not exceed 1 hour. Refresh Tokens must use rotation — each use issues a new token and revokes the previous one. This limits the blast radius of a stolen token.

�� Scope Minimization

Request only the scopes actually required by the operation. Broad scopes (e.g., User.ReadWrite.All) should require justification and just-in-time approval where possible.

⚠️

Always validate these JWT claims: iss (correct issuer),n�aud (correct audience), exp (not expired), nbf (not before). Skipping any one of these is a critical vulnerability.

Authorization Code + PKCE Flow

1. Generate code_verifier and code_challenge (SHA256). 2. Redirect user to /authorize with code_challenge. 3. Exchange code + code_verifier for tokens. 4. Store access token in memory only — never localStorage.

Client Credentials with Managed Identity

1. Assign Managed Identity to the cal