11.4 Web Application Firewall and API Management Protection

11.4 Web Application Firewall and API Management Protection

Quick Answer: SC-500 measures Azure Web Application Firewall and security policies for back-end API protection by using API Management. Place WAF on Application Gateway or Azure Front Door to stop common web exploits; use APIM policies (validate-jwt, rate limits, ip-filter, backend auth) so APIs are not a naked public surface. For AI Gateway in front of Microsoft Foundry, see chapter 9—this section is the general platform foundation.

Even a perfectly configured App Service still runs application code that can be vulnerable to injection, protocol abuse, and automated bots. WAF and APIM are the edge control planes for HTTP and API traffic under application platform security.

Azure Web Application Firewall placement

Azure WAF is a service capability attached to global or regional entry points:

Both evaluate HTTP(S) requests against WAF policies before traffic reaches healthy backends (when correctly architected so clients cannot bypass the WAF).

Bypass prevention (exam theme)

WAF only helps if attackers cannot hit the origin directly:

• Lock App Service with access restrictions allowing only Front Door/App Gateway identifiers as documented
• Or use private origins (Private Link to App Service / internal load balancers) so the public only sees the edge

Exam trap: Enabling WAF while leaving the App Service fully public with no origin filter = attackers skip the WAF.

Managed rule sets and OWASP

WAF policies include managed rule sets that encode protections aligned with common web attack classes (SQL injection, XSS, protocol anomalies, remote file inclusion patterns, and more)—often discussed in OWASP Top 10 terms.

You do not need to memorize every rule ID for SC-500. You do need to know that managed rules cover OWASP-class web attacks, that custom rules extend policy for business logic (block country X, allow partner IP Y), and that bot protection is a first-class managed set.

Prevention vs Detection

Operational pattern (same spirit as Conditional Access report-only):

1. Deploy WAF in Detection.
2. Review logs (Log Analytics / Sentinel).
3. Add exclusions for legitimate traffic that trips rules (for example unusual but valid headers).
4. Switch to Prevention.
5. Monitor blocked requests and backend health.

Exam trap: Leaving production internet apps in Detection forever “to be safe” fails the goal of blocking attacks. Detection is a phase, not the end state for exposed critical apps.

Custom rules and bot protection (high level)

Custom rules

Custom rules evaluate match conditions and take actions such as Allow, Block, Log, Redirect, or rate-based controls (feature set depends on Front Door vs Application Gateway SKUs).

Examples:

• Block known-bad IP ranges
• Geo-filter admin paths
• Rate-limit extreme request rates from a single IP
• Allow a monitoring probe path that would otherwise trip a managed rule (carefully)

Order matters: custom rules are processed with priority numbers; an early Allow can short-circuit later inspection depending on policy design—understand priority when tuning.

Bot protection

Bot Manager-type rule sets classify automated traffic. Strategies include:

• Allow verified good bots (search engines) if desired
• Block malicious bots
• Challenge or log unknown bots (capabilities vary by product generation)

SC-500 level: know bot protection exists as managed rules, not the deep ML training details.

Azure API Management for backend API protection

Azure API Management (APIM) is a managed API gateway. SC-500 explicitly calls out security policies for back-end API protection. Think of APIM as policy middleware between clients and your Functions, App Service, Logic Apps, AKS services, or other APIs.

Inbound policy toolkit (memorize these)

Backend protection patterns

1. Do not expose backends publicly when APIM is the front door—use private endpoints, VNet-injected APIM modes, or access restrictions allowing only APIM.
2. Authenticate APIM to the backend with managed identity; enable Easy Auth on the backend accepting only APIM’s app ID.
3. Least privilege products and subscriptions for external partners.
4. Named values referencing Key Vault for secrets used in policies.
5. Diagnostics to Log Analytics for failed JWT validations and spike detection.

validate-jwt exam focus

When a scenario says partners call with OAuth2 access tokens, the APIM answer is almost always validate JWT (or the Entra-specific validation policy) before the request reaches the backend. Check:

• Signing keys / OpenID metadata
• Audience matches the API
• Issuer is your Entra tenant (or expected IdP)
• Required roles/scopes
• Expiry enforced

Subscription keys alone do not prove user/app identity with the same strength as JWT validation for Entra-protected enterprise APIs.

WAF and APIM together

They complement; they do not replace each other.

Common design: Internet → Front Door WAF → APIM → private Function/App Service. WAF blocks SQLi/XSS noise; APIM enforces partner contracts and JWT; backend trusts only APIM’s managed identity.

For purely regional private APIs, Application Gateway WAF may sit in the hub instead of Front Door.

Cross-reference: AI Gateway (chapter 9)

Chapter 9.4 Defender for AI, Foundry Guardrails & AI Gateway covers configuring AI Gateway in Azure API Management for Microsoft Foundry—token limits, auth, logging, and governance specific to model/agent endpoints. Those controls build on the same APIM policy engine introduced here (validate-jwt, rate limits, managed identity backends, observability). On SC-500:

• Use this section for general web/API edge security (WAF modes, OWASP rules, classic API protection policies).
• Use chapter 9 when the backend is Foundry / AI and the gateway is explicitly an AI Gateway pattern.

Do not invent a separate product that “replaces APIM” for AI; Microsoft’s measured skill is AI Gateway in APIM for Foundry scenarios.

Scenario: public payments API

Contoso exposes /payments to fintech partners.

1. Front Door Premium + WAF in Prevention with DRS + Bot Manager; custom rule rate-limits extreme clients.
2. Origin is APIM (public or via Private Link patterns as designed); backends not directly public.
3. APIM inbound: validate-jwt (audience api://payments, scope payments.write), rate-limit-by-key per partner app ID, optional ip-filter for registered partner ranges.
4. Backend Function: Easy Auth + only APIM managed identity; Function MI to Key Vault and Cosmos DB.
5. Logs: WAF + APIM diagnostics → Sentinel for JWT failure spikes and blocked SQLi attempts.

SC-500 traps

1. WAF Detection forever — Must move critical apps to Prevention after tuning.
2. APIM subscription key equals Entra user auth — Keys identify subscriptions; JWT validates identity tokens.
3. WAF replaces input validation in code — Defense in depth; developers still fix vulnerabilities.
4. Public backend behind “secret URL” — Bypasses gateway controls; lock origin.
5. Confusing Azure Firewall with WAF — Firewall is broader network filtering; WAF is HTTP application inspection on App Gateway/Front Door.
6. Mixing AI Gateway details here — Keep Foundry-specific AI Gateway content tied to chapter 9 skills.

Engineer checklist

1. Choose Front Door WAF (global) vs Application Gateway WAF (regional) based on architecture.
2. Start managed rules in Detection, tune, then Prevention.
3. Add custom rules and bot protections appropriate to risk.
4. Ensure origins cannot be bypassed.
5. Front APIs with APIM; apply validate-jwt, rate-limit, ip-filter as needed.
6. Authenticate APIM → backend with managed identity; harden backend Easy Auth/network.
7. Centralize logs; alert on block spikes and auth failures.
8. For Foundry/AI front doors, apply chapter 9 AI Gateway patterns on the same APIM foundation.

Bottom line: SC-500 application edge security is WAF for malicious HTTP plus APIM for identity-aware API contracts. Configure both, close bypass paths, and remember AI Gateway is the specialized APIM application of these ideas for Foundry—not a totally separate exam silo.