A retail chain's Meraki Dashboard posts port-down alerts to an internal service that also ingests events from two other vendors' monitoring tools. The team must confirm each alert truly came from Meraki before acting on it. Which webhook validation control should the service enforce first?
Select an answer to reveal the explanation.
Short Explanation
You're checking the signed seal on a delivery, not the paint on the truck — the shared secret lets your service verify that the alert was signed by someone with the secret. Encryption and firewall rules protect the trip, but only the signature validates the message.
Full Explanation
Meraki Dashboard computes an HMAC-SHA1 over the exact raw request body using the shared secret configured for that webhook, then sends the base64 result in the X-Cisco-Meraki-Signature header. When your service recomputes the HMAC and matches it, you verify that the sender holds the secret without the secret ever travelling over the wire. Terminating TLS with a trusted certificate authenticates the encrypted channel, not the producing application, so transport security alone leaves a spoofed origin unverified. Source-IP allowlisting treats Dashboard egress addresses as a stable identity, yet those ranges are not guaranteed to stay fixed and your endpoint must still accept other vendors' events, so an address filter cannot be the identity check. Validating organization and network identifiers inside the JSON is circular, because an attacker who can post a fake alert can simply copy valid identifiers from a captured one. Practical check: replay one captured alert with a single character altered in the body and confirm your service drops it.