11.3 Azure App Service Security
Key Takeaways
- Enforce HTTPS only and a modern minimum TLS version (typically TLS 1.2+) on Azure App Service to protect data in transit.
- Use access restrictions and private endpoints / VNet integration to control inbound and outbound network paths for web apps.
- App Service Authentication (Easy Auth) with Microsoft Entra provides platform-level auth without custom middleware.
- Managed identity plus Key Vault references keeps secrets out of plain app settings and source code.
- Lock down SCM/Kudu and FTP/FTPS management surfaces; treat deployment endpoints as high-value attack paths.
11.3 Azure App Service Security
Quick Answer: SC-500 requires you to implement and configure security controls for Azure App Service. Master HTTPS-only and TLS versions, access restrictions, private endpoints and VNet integration, Easy Auth / Entra, managed identity, Key Vault references for app settings, SCM/Kudu lockdown, and client certificates at an overview level.
Azure App Service hosts web apps, APIs, and mobile backends on a managed platform. You do not patch the underlying VM OS the same way as IaaS, but you own the configuration surface attackers probe first: public endpoints, weak TLS, open Kudu, secrets in app settings, and missing authentication.
Transport security: HTTPS and TLS
HTTPS only
Enable HTTPS Only so HTTP requests redirect to HTTPS. This prevents accidental cleartext use of cookies, tokens, and form posts on the public endpoint.
Minimum TLS version
Configure the minimum TLS version (commonly 1.2 or higher in modern baselines). Older TLS versions and weak ciphers are frequent compliance findings.
| Setting | Exam-ready guidance |
|---|---|
| HTTPS Only | On for all production apps |
| Minimum TLS | 1.2+ (follow current Microsoft defaults/compliance policy) |
| TLS cipher suites | Prefer platform defaults unless compliance dictates a custom suite order |
| HTTP/2, WebSockets | Enable as needed; not a substitute for auth/network controls |
| Custom domains + certificates | Use App Service managed certificates or certificates from Key Vault; monitor expiry |
Exam trap: “We use HTTPS in the app code” is incomplete if the platform still allows HTTP or TLS 1.0 at the front end. Set platform HTTPS Only and min TLS.
Access restrictions (inbound allow/deny lists)
Access restrictions filter traffic to the App Service public endpoint by:
- IPv4/IPv6 address ranges
- Virtual Network rules (service endpoints / subnet delegation patterns)
- Service tags in supported scenarios
Use cases:
- Allow only corporate egress IPs during migration
- Allow only Azure Front Door / Application Gateway backend traffic (with proper header validation patterns where documented)
- Deny all by default, then add explicit allows
Access restrictions are not full Zero Trust identity. Pair them with Easy Auth and, for stronger isolation, private endpoints.
Private endpoints and VNet integration
These are different directions of traffic—do not confuse them.
| Feature | Direction | What it solves |
|---|---|---|
| Private endpoint | Inbound to App Service | Clients in a VNet reach the app on a private IP; you can disable public network access |
| VNet integration | Outbound from App Service | App reaches private resources (SQL PE, storage PE, internal APIs) via a delegated subnet |
| App Service Environment (ASE) v3 | Full environment isolation | Single-tenant, always VNet-injected hosting for high isolation needs |
Private endpoint checklist
- Create private endpoint to the web app (sites) resource.
- Configure private DNS zone for
privatelink.azurewebsites.net. - Set public network access to disabled when ready.
- Remember SCM may need its own consideration—management plane endpoints can be restricted separately.
- Ensure callers (APIM, App Gateway, peer VNets) have network path and DNS resolution.
VNet integration checklist
- Delegate a subnet for VNet integration.
- Integrate the app; enable Route All when all outbound should hairpin through the VNet.
- Use private endpoints on dependencies; do not rely on public PaaS IPs if the goal is private-only.
- NSG/UDRs on the integration subnet must allow required egress (including to Azure services via PE).
Exam trap: Private endpoint alone does not force the app’s outbound calls through your VNet—that is VNet integration. Many designs need both.
Easy Auth / Microsoft Entra authentication
App Service Authentication (Easy Auth) runs in the platform front end:
- Redirects unauthenticated users to Entra (or other providers)
- Validates tokens for APIs
- Can require authentication for all requests or allow anonymous with code-level checks
- Supports Microsoft Entra ID, social IdPs, and OpenID Connect providers
Why security engineers like Easy Auth
- No custom auth middleware required for baseline protection
- Centralizes token validation configuration
- Works consistently for App Service and Functions
- Combines with Conditional Access on the Entra app when users sign in interactively
Configuration themes
| Topic | Guidance |
|---|---|
| Unauthenticated requests | Return 401/403 for APIs; redirect for browser apps |
| Token store | Understand platform token handling for server-side flows |
| Client secret vs federated credentials | Prefer managed identity / federated credentials for app credentials where applicable |
| Allowed audiences | Restrict tokens to the correct app API URI |
Easy Auth is not a WAF. It does not stop SQL injection in your code. Put WAF in front for HTTP exploit filtering (section 11.4).
Managed identity and Key Vault references
Managed identity
Enable system-assigned or user-assigned identity on the web app. Grant least-privilege RBAC to Azure resources. Use the Azure Identity libraries in code or platform features that fetch tokens automatically.
Key Vault references in app settings
Instead of pasting secrets into Application Settings:
@Microsoft.KeyVault(SecretUri=https://contoso-kv.vault.azure.net/secrets/DbPassword/)
Requirements:
- App has managed identity.
- Identity has secret get permissions (RBAC Key Vault Secrets User or access policy equivalent).
- Network path to Key Vault works (public allow + trusted services, or private endpoint + VNet integration as documented).
| Anti-pattern | Better approach |
|---|---|
| Connection string with password in app settings | Key Vault reference + MI |
| Secret in source code | Key Vault + MI |
| One MI with Contributor everywhere | Least-privilege data-plane roles |
| Vault firewall blocking platform resolve | Align KV network rules with App Service integration/PE guidance |
SCM / Kudu lockdown
Every App Service has a SCM (Kudu) site used for deployment, logs, process explorer, and advanced tools—historically a juicy target if left open.
Hardening practices:
- Restrict SCM access with the same rigor as the main site (access restrictions / private access patterns).
- Prefer secure deployment (CI/CD with OIDC federated credentials to Azure, run-from-package) over standing FTP.
- Disable FTP or require FTPS only; better yet, disable FTP endpoints if unused.
- Limit who has Website Contributor / publish profile download rights.
- Rotate publish profiles if they were shared; prefer RBAC + pipeline identities.
Exam trap: Securing only the main site hostname while leaving *.scm.azurewebsites.net wide open is incomplete.
Client certificates (overview)
App Service can require client certificates (mutual TLS) so callers present a certificate before the request reaches the app.
| Use case | Notes |
|---|---|
| B2B API requiring device/app certs | Enable client cert mode; app validates cert thumbprint/claims as designed |
| Extra factor beyond Entra | Sometimes layered; often Entra alone is preferred for user auth |
| APIM to backend mTLS | Certificates may be presented by the gateway instead of end users |
Know that client certs are an option for service identity; for user sign-in, Entra remains primary on SC-500.
Defense-in-depth stack for a web API on App Service
- Front Door or Application Gateway + WAF (internet edge).
- Backend App Service with access restrictions allowing only the gateway (or private backend).
- HTTPS Only + TLS 1.2+.
- Easy Auth requiring Entra tokens for API calls.
- Managed identity to SQL/Storage/Key Vault.
- Secrets via Key Vault references.
- SCM locked down; FTP disabled.
- Diagnostics to Log Analytics; Defender recommendations remediated.
Scenario: “ elevating” a legacy public app
Fabrikam’s HR portal is public, HTTP allowed, secrets in app settings, FTP enabled for a vendor.
Remediation order that matches SC-500 thinking:
- Turn on HTTPS Only and raise min TLS (quick win).
- Move secrets to Key Vault references + managed identity.
- Enable Easy Auth with Entra; remove local username tables if possible.
- Put WAF in front; tighten access restrictions.
- Disable FTP; restrict SCM; move vendor to pipeline-based deploy.
- Plan private endpoint if the app should leave the public internet entirely.
SC-500 traps
- VNet integration = private inbound — False; that is outbound (plus ASE special cases).
- Easy Auth replaces TLS — You still need HTTPS/TLS.
- Key Vault reference without MI permissions — Reference shows unresolved / app fails to start correctly.
- Publish profile as long-term vendor access — Prefer federated pipeline identity and RBAC.
- Client certificates required for every browser user — Usually the wrong UX; Entra interactive auth is the user path.
Engineer checklist
- HTTPS Only + minimum TLS 1.2+.
- Decide public vs private inbound; configure access restrictions or private endpoints.
- VNet integration for private outbound dependencies.
- Easy Auth with Entra for user/API identity.
- Managed identity + Key Vault references; purge plain secrets.
- Disable FTP; restrict SCM/Kudu; secure CI/CD.
- Review client certificate needs for service callers only.
- Enable diagnostics and track Defender for Cloud recommendations for App Service.
Bottom line: App Service security on SC-500 is platform configuration excellence—transport, network, identity, secrets, and management plane—before you debate application framework details.
What is the primary purpose of enabling HTTPS Only on an Azure App Service web app?
An App Service must call a SQL Database private endpoint and must not be reachable from the public internet. Which pairing is required?
How should production App Service secrets be stored according to SC-500-aligned practice?
Why is locking down the SCM/Kudu endpoint important when hardening Azure App Service?