A Python receiver in a warehouse collects Meraki alerts into an incident log. The HTTP server in Dashboard was set up with a shared secret, and every POST body carries that secret with alertType, networkId and sentAt. Which validation should the webhook handler run before it saves the alert?
Select an answer to reveal the explanation.
Short Explanation
Meraki doesn’t send a signature header, so an HMAC check would reject legitimate alerts. Treat the shared secret like a key: compare the value in the JSON body with the one you configured, and reject the request if they don’t match before saving the alert.
Full Explanation
Meraki alert webhooks include a shared secret in the JSON body. The receiver must parse the body to read that field, compare it with the value saved when the HTTP server was configured, and refuse requests with a mismatch before logging them. A constant-time comparison avoids leaking the secret through response timing. An HMAC check fails because Meraki does not send a signature header with these alerts. Filtering on Meraki's published source addresses can be a coarse additional layer, but those ranges do not prove a post came from your configuration. Checking sentAt can help reject stale messages, but it does not authenticate the sender. A practical check is to replay a captured alert with the secret altered and confirm the handler returns an error without writing a row.