AZ-204 practice question 26 of 35

You are building an application to track cell towers that are available to phones in near real time. A phone will send information to the application…

Full set: 489 questions

Domain Implement Azure security

You are building an application to track cell towers that are available to phones in near real time. A phone will send information to the application by using the Azure Web PubSub service. The data will be processed by using an Azure Functions app. Traffic will be transmitted by using a content delivery network (CDN). The Azure function must be protected against misconfigured or unauthorized invocations. You need to ensure that the CDN allows for the Azure function protection. Which HTTP header should be on the allowed list?
Answer options
A: WebHook-Request-Origin Correct answer
B: Resource
C: Authorization
D: WebHook-Reauest-Callbackuirements
Correct Answer:
A. WebHook-Request-Origin
Explanation

Azure Web PubSub secures its webhook event handlers, such as an Azure Function, using the CloudEvents Abuse Protection mechanism. In every request sent to the webhook, the Web PubSub service includes the WebHook-Request-Origin HTTP header. This header contains the domain name of the service instance (e.g., contoso.webpubsub.azure.com). The Azure Function code should validate this header to ensure that the invocation originates from the expected Azure Web PubSub service. Therefore, the Content Delivery Network (CDN) must be configured to allow this header to pass through to the function for this validation to occur.

Why Incorrect

B. Resource: This is not a standard HTTP header used by the Azure Web PubSub service for webhook validation or abuse protection.
C. Authorization: While a standard header for authentication, the specific mechanism for Web PubSub webhook origin validation relies on the WebHook-Request-Origin header, not a bearer token or other credentials in the Authorization header.
D. WebHook-Request-Callback: This header is used only during the initial one-time validation handshake (an OPTIONS request) to prevent webhook abuse, not for validating every subsequent event invocation.

References

1. Microsoft Docs - Azure Web PubSub service concepts - Event handler: Under the "Upstream endpoint validation" section, it states, "For every WebHook event request, the service adds WebHook-Request-Origin and WebHook-Request-Rate to the request. If your upstream is an Azure Function with Web PubSub trigger, you don't need to validate this header in your function code... But for other function environments... you need to validate the request is from the service." This confirms the header's purpose for protection.

Source: Microsoft, "Event handler in Azure Web PubSub service," Azure Web PubSub Documentation, learn.microsoft.com/en-us/azure/azure-web-pubsub/concept-event-handler#upstream-endpoint-validation.

2. CloudEvents Specification v1.0.2 - HTTP Webhook Delivery: The Azure Web PubSub implementation is based on this standard. Section 4.1, "Origin Validation," specifies: "The HTTP WebHook-Request-Origin header field MAY be used by the sender to identify itself... The receiver SHOULD then validate that the value of the WebHook-Request-Origin header field is a domain name that it expects."

Source: Cloud Native Computing Foundation, "CloudEvents - Version 1.0.2, HTTP Webhook Delivery," GitHub, github.com/cloudevents/spec/blob/v1.0.2/http-webhook.md#41-origin-validation.

Scroll to Top