4.3.3. Azure App Service, Web Application Firewall, and API Management Protection
💡 First Principle: A public-facing web app or API needs protection at two layers that address different threats — edge-level filtering of known attack patterns before they ever reach application code, and the application's own authentication, authorization, and configuration — and neither layer substitutes for the other.
Azure App Service security includes authentication/authorization integration (App Service's built-in auth, or Entra ID directly), managed identity usage for downstream calls, and network restrictions (access restrictions, VNet integration, private endpoints). Web Application Firewall (WAF), deployed via Azure Application Gateway or Azure Front Door, filters known attack patterns — SQL injection, cross-site scripting, and other OWASP Top 10 categories — at the edge, before traffic reaches the app. API Management's back-end API protection includes rate limiting, subscription keys or OAuth-based authentication, and IP filtering to protect back-end APIs from abuse and unauthorized access, functioning as a policy enforcement point in front of the actual API implementation.
⚠️ Exam Trap: A WAF blocking a known SQL injection pattern doesn't mean the application's own input validation and parameterized queries are unnecessary — WAF is a layer of defense in depth (Phase 1), not a replacement for secure application code. A scenario asking "is the application now safe from SQL injection because WAF is enabled" is testing whether you'll correctly say no.
Reflection Question: If both a WAF and API Management sit in front of the same App Service app, what distinct kind of protection does each one add that the other doesn't cover?
