API Security Design Field Guide
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.
📋 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.
🌐 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.
Broken Object Level Authorization
Accessing another user's objects by manipulating resource IDs in the request.
Broken Authentication
Weak tokens, brute force susceptibility, or exposed credentials in requests.
Broken Object Property Level Auth
Returning sensitive fields that should not be exposed (mass assignment / over-exposure).
Unrestricted Resource Consumption
No rate limiting allows DoS attacks and cost attacks on cloud-billed APIs.
Broken Function Level Authorization
Admin-only functions accessible to regular users due to missing role checks.
Unrestricted Access to Sensitive Business Flows
Ticket scalping, account enumeration, bulk discount abuse, and similar automation attacks.
🛡️ 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.
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 — no 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.
iss (correct issuer), 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 calling service (App Service, Function, ACI). 2. Grant API permissions in Entra ID app registration. 3. Use DefaultAzureCredential — no secret storage required. 4. Set short token cache TTL (max 1 hour).
MSAL + Authorization Code + PKCE
Use the Microsoft Authentication Library (MSAL) for iOS/Android. MSAL handles PKCE, token caching, and silent refresh automatically. Never implement OAuth flows manually in mobile apps.
🔍 Defender for APIs
Defender for APIs (part of Microsoft Defender for Cloud) provides runtime visibility into your API landscape, discovering unmanaged endpoints and detecting anomalous traffic patterns.
🕵️ Shadow API Discovery
Identifies APIs that are reachable from the internet but not registered in Azure API Management — the most dangerous blind spot in API security.
📊 Anomaly Detection
Detects unusual traffic: off-hours spikes, suspicious source IPs, unusual parameter patterns, and sudden increases in error rates.
🔒 Sensitive Data Discovery
Flags APIs that return PII, credentials, or keys in response bodies — helping identify data over-exposure (OWASP API3).
📋 MCSB Mapping
Findings are mapped to Microsoft Cloud Security Benchmark controls, making it easy to tie API risks to your broader compliance posture.
Enable Defender for APIs
Enable in Defender for Cloud
Navigate to Defender for Cloud → Environment Settings → [Your Subscription] → Defender Plans and enable APIs. Pricing is per API call volume.
Review API Inventory
The API Security blade shows all discovered APIs across APIM instances. Review the "Unprotected APIs" list immediately — these are your highest-risk exposure points.
Configure Alerts
Set up alert rules for: high 401/403 rates (brute force), sudden traffic spikes (DoS), and sensitive data detection. Route alerts to your SIEM via Defender for Cloud's export connector.
✅ API Security Implementation Checklist
Use this checklist when deploying new APIs or auditing existing ones.
🛡️ Core Protection- All APIs sit behind Azure API Management — no direct backend exposure to the internet
- JWT Validation policy configured on every API in APIM (validate-jwt with Entra ID)
- Rate Limiting and Quota policies applied — no unbounded API access
- CORS policy set with specific allowed origins — no wildcard (*)
- Web/SPA apps use Authorization Code + PKCE — not Implicit Flow
- Service-to-Service calls use Managed Identity — no client secrets in code
- Access Token lifetime ≤ 1 hour with Refresh Token rotation enabled
- JWT claims validated: iss, aud, exp, nbf on every request
- Scopes minimized — no overly broad permissions granted
- Defender for APIs plan enabled in Defender for Cloud
- API inventory reviewed — zero unprotected shadow APIs
- Alert configured for 401/403 spikes (potential brute force or credential stuffing)
- Sensitive data findings reviewed and remediated in Defender for APIs
- API logs flowing to Sentinel or SIEM via Defender for Cloud connector