Implement security for application platform services

Elmcroft Health publishes a patient-records API through Azure API Management. Client applications obtain access tokens from Microsoft Entra ID for an app registration whose application ID URI is api://patient-records. API Management must reject any request whose token was not issued by the company's tenant for that audience, and must reject tokens that lack the Records.Read role, before the request reaches the back end. The back-end code must not change.

Which inbound policy should you add?

1. Avalidate-azure-ad-token with the tenant ID, an audiences element containing api://patient-records, and a required-claims element requiring the roles claim to contain Records.Read.validate-azure-ad-token is purpose-built for Microsoft Entra ID tokens: it checks issuer and signature for the tenant, enforces the audience, and can require specific claim values such as roles.
2. Bcheck-header that requires the Authorization header to be present.check-header verifies only that a header exists or has a fixed value; it does not validate token signature, issuer, audience, or claims.
3. CRequire a subscription key on the product and set subscriptionRequired to true.Subscription keys identify API Management subscribers; they are not identity tokens and do not enforce audience or role claims.
4. Dip-filter with an allow list of the client applications' IP addresses.IP filtering restricts source addresses but provides no assurance of the caller's identity or authorization.

Pemberly Travel has an HTTP-triggered Azure Functions app named func-bookings that is called by a single-page application. Today the function uses an anonymous authorization level. Security requires that every caller present a valid Microsoft Entra ID token issued to the company's tenant, and the function code must not be changed.

What should you configure?

1. AChange the HTTP trigger's authLevel to function and distribute the function key to the application.Function keys are shared secrets, not user identities; they do not validate Entra tokens, and changing authLevel is a code or metadata change.
2. BEnable App Service authentication (Easy Auth) on func-bookings with the Microsoft identity provider and set unauthenticated requests to return HTTP 401.Easy Auth runs as a platform middleware in front of the function host and validates Entra tokens for every request before the function code executes, with no code change.
3. CAdd a Key Vault reference to the function app settings for the client secret used by the single-page application.Key Vault references deliver secrets to app settings; they do not authenticate incoming requests.
4. DPlace the function behind Azure Front Door and enable the Web Application Firewall managed rule set.WAF inspects requests for attack patterns; it does not validate identity tokens or reject unauthenticated callers.

Cairnwood Publishing protects a content management web app with an Application Gateway WAF v2 policy in Prevention mode using the OWASP 3.2 managed rule set. Editors report that saving articles that contain SQL code samples is blocked. The WAF logs show rule 942100 in the SQLI rule group matching the request body field named articleBody. The security team requires that other requests, and other fields in the same request, remain fully protected.

What should you do?

1. ASwitch the WAF policy to Detection mode.Detection mode logs but never blocks any rule, which removes protection for the entire application.
2. BDisable the SQLI rule group in the managed rule set.Disabling the whole rule group removes SQL injection protection for every request and field, far beyond the single false positive.
3. CAdd a per-rule exclusion for rule 942100 that excludes the request body post argument named articleBody from evaluation.Per-rule exclusions in Application Gateway WAF v2 scope the exemption to a specific rule and a specific match variable, so the rest of the request and all other rules continue to be enforced.
4. DCreate a custom rule with priority 1 that allows all requests to the article save path.An allow custom rule with the highest priority bypasses all managed rules for every request on that path, leaving it unprotected.

Marlin Ticketing serves its public website through Azure Front Door Premium with a WAF policy that uses the Default Rule Set. During ticket releases, the login endpoint at /api/login receives bursts of password-guessing attempts from individual IP addresses. The security team wants any single client IP address that sends more than 100 requests to /api/login within one minute to be blocked, without affecting traffic to other paths.

What should you add to the WAF policy?

1. AA custom rule of type rate limit, with a threshold of 100 requests per 1 minute, a match condition on the request URI containing /api/login, and the action Block.Front Door WAF rate-limit custom rules count requests per client address over a one- or five-minute window for requests matching the conditions and block the client once the threshold is exceeded.
2. BThe Microsoft_BotManagerRuleSet managed rule set in Block mode.Bot Manager classifies known bad, good, and unknown bots by signature and reputation; it does not enforce a numeric per-IP request threshold on a specific path.
3. CA custom rule of type match with a geo-location condition that blocks requests from outside the sales regions.Geo-filtering restricts by country or region and would not stop high-volume attempts from allowed regions, nor is it specific to the login path.
4. DUpgrade the managed rule set to the latest Default Rule Set version and set the policy to Prevention mode.The managed rule set detects attack signatures such as injection; it does not implement request-rate thresholds.