A public customer portal uses Azure App Service for its front end, Azure Functions for asynchronous tasks and an internal API that can approve account changes. The team has enabled HTTPS and placed a web application firewall in front of the site. During a review, an engineer discovers that the back-end API is reachable through a separate hostname and accepts a credential shared by several applications. The presence of WAF protection on the visible website does not establish the security of the transaction behind it. The Microsoft SC-500 exam expects security engineers to protect application-platform services, API Management policies, network paths and execution identities as distinct controls.
The broader VM and container security guidance introduces platform hardening and cloud workload boundaries. Here the focus is the managed application layer: who can invoke each endpoint, where incoming traffic is filtered, what identity the application uses downstream, how secrets are managed and which operations should be denied independently of the web request being syntactically valid.
Draw every entry point, not just the public homepage
Inventory the App Service hostname, custom domains, deployment slots, Functions HTTP triggers, Logic Apps endpoints, API Management gateway, origin back ends and any administrative or health routes. A WAF protects only traffic that actually flows through its configured entry point. If the same application can be reached directly at an exposed origin, a restrictive WAF rule may be bypassed. Likewise, a private endpoint can constrain network reachability without proving that an authenticated caller is authorized to modify a customer account.
For the account portal, list the approved traffic path from external client to WAF, application, API and data service. Then attempt the same operation through the origin hostname and a direct API endpoint. Where the architecture requires mediated access, the bypass should fail. Record where each request was rejected and by which control. This exercise avoids the common mistake of validating only the attractive path drawn on the latest diagram while leaving older endpoints and integration routes available to attackers.
App Service authentication belongs in a complete design
App Service authentication and authorization features can validate identities for applicable requests, but authorization for a specific customer record or account action may need to be enforced by application logic. Determine whether the service accepts Microsoft Entra identities, external identities or another supported authentication model, and validate issuer, audience and role claims appropriately. An authenticated user should not be able to submit a different customer identifier in the request body and thereby gain access to that person’s records.
Establish who can change App Service configuration, deploy code or swap deployment slots. Administrative access to the hosting platform may have different implications from runtime access by a portal user. Application consent and Conditional Access define important identity and grant boundaries; this service still must enforce the application’s own business rules. Test the same sensitive action with an entitled account, a normal unrelated customer, an expired token and a token for the wrong audience.
Protect Functions and Logic Apps as independent execution surfaces
A Function triggered by an HTTP request can become an unguarded alternative to the main portal. Review supported authentication and authorization methods, network restrictions, and any function keys or shared secrets that would permit execution. Function-level access keys should not be treated as a perfect substitute for caller identity and specific business authorization. Event-triggered Functions introduce other risks: a trusted queue message might come from a misconfigured producer or contain unexpected data that influences a privileged downstream action.
Logic Apps connect multiple business and infrastructure services. Each connector and workflow identity should have the minimum required permission, and the security team should understand which person or workload can change the workflow. An automation that creates an account update should validate idempotency and human approvals where necessary; repeated messages must not create duplicated financial transactions. Use environment separation and versioned deployments to prevent a test workflow from calling production resources accidentally.
Use API Management to enforce caller and backend boundaries
Azure API Management can act as a managed API gateway, but the mere existence of an instance does not mean all backends are protected. Define which routes must go through it, how client identity is checked, and what credential the gateway uses to reach each backend. Enforce appropriate JWT claims, rate limits, network rules or other supported policies, while keeping the actual business authorization in the service that owns the data and transaction. A request that matches a valid schema can still be unauthorized or malicious.
For an application that calls a Foundry model, APIM can also provide an AI-specific gateway policy, but the model-facing concerns differ from an ordinary account-management API. Foundry AI Gateway controls address token quotas, model deployment routing and agent safeguards. Don’t use an LLM quota rule to justify bypassing customer authorization or a WAF to pretend a prompt-injection scenario has been solved; each control is best judged against the threat it can genuinely prevent or detect.
WAF rules address HTTP-layer threats, not every application mistake
A web application firewall can inspect applicable HTTP requests for suspicious patterns, provide managed or custom rules and help restrict abusive traffic. Its rule set requires tuning against legitimate application behavior, because overaggressive blocking can disrupt normal forms or APIs. Conversely, an alert-only configuration may record traffic without preventing the underlying exploit. Security engineers must distinguish the deployed policy action from the existence of a published rule. Review logging and blocked-request traces for the actual listener through which traffic enters the application.
Imagine the portal’s search form uses a filter syntax that resembles a malicious payload. Before permanently disabling the relevant WAF rule, inspect the request, application parsing, intended operation and risk of exploitation. Prefer a narrow validated exclusion or code-level fix when warranted. Network security and private access identify where WAF rules sit relative to firewalls, private endpoints and VNet restrictions. WAF protection does not replace service-to-service identity or authorization checks on the origin.
Store keys and certificates away from application source
App Service and Functions often need secrets for upstream and downstream integrations. Prefer managed identities and supported secret references where practical rather than hardcoding credentials in source files or deployment variables visible to broad teams. Review who may read or update configuration settings, because access to environment variables or deployment logs can reveal sensitive information. Place certificates under appropriate lifecycle controls and plan renewal and emergency replacement before an outage creates pressure to weaken validation.
If an application depends on Azure Key Vault, validate both the application’s access permissions and the vault’s network restrictions. A managed identity that can request a token for Azure is not automatically entitled to read a vault secret. Separate secret administrators from routine runtime consumers and use diagnostic evidence for sensitive access. Key Vault recovery, RBAC and audit controls remain important even when an application uses identity-based access to minimize stored credentials.
Defend the deployment path as carefully as runtime
Application code, platform settings, endpoint mappings and policy changes should pass distinct release checks. A development slot may be a useful staging environment but should not be assumed to have the same public exposure, secrets or access restrictions as production. Review what happens during slot swaps and configuration changes, including which settings are slot-specific, and test whether a production secret can accidentally leak into nonproduction. Restrict identities that can change API gateway policy or WAF settings just as carefully as identities that deploy application code.
A release checklist should include a positive customer transaction, a forbidden customer transaction, a direct-origin bypass attempt and a failure of a dependent service. It should also confirm the relevant security events are observable without logging raw credentials or regulated customer data. Document how to roll back a policy or code change while keeping the denial boundaries in place; an emergency deployment that temporarily permits everyone to access the back end creates a security incident even if the customer-facing page becomes available again.
There is also a subtle operational problem when a public API and a private back end use different authentication methods. A healthy front-end session might be accepted while the backend managed identity loses a role assignment, yielding an application error that looks like a general authorization failure. Conversely, a service-side permission may remain valid while a new WAF rule blocks only a particular request body. To distinguish these cases, propagate a non-sensitive correlation identifier from the edge through API Management and the application to its authorized downstream dependencies. Make sure every monitoring team knows what that identifier means and who may access the corresponding evidence. Troubleshooting should never require copying raw access tokens into a support ticket.
Diagnose layered failures without removing safeguards
If users cannot reach the portal, identify whether DNS, WAF, firewall, application authentication, API Management, backend identity or business-logic authorization rejected the request. The HTTP status alone may not distinguish every case. Correlate logs and identifiers across those layers and test with a known permitted request. Avoid the tempting response of disabling both the WAF and API validation just to see whether the application works; that experiment removes several controls at once and obscures the actual fault.
Trace application access through every enforcement point: network reachability, WAF inspection, caller authentication, API Management policy, managed workload identity and the backend’s transaction authorization. A control at one layer does not automatically secure another exposed hostname or an overpowered integration credential. Test an allowed transaction and a deliberate invalid operation before the architecture is declared protected.