Your Flask service receives Meraki alert webhooks on a public URL and must check that each alert includes the secret configured for your dashboard before it opens a ticket. Which validation should your handler perform first?
Select an answer to reveal the explanation.
Short Explanation
Meraki includes a shared secret in the alert body, so your handler can compare that value with the one configured on the dashboard before opening a ticket. Reject messages whose values differ. This checks that the sender supplied the configured secret; it does not by itself prevent replay of a previously captured valid alert.
Full Explanation
Meraki alert webhooks include the configured secret in a sharedSecret field in the JSON payload. Your handler can compare that field with the value stored on the dashboard and reject mismatches before opening a ticket. A timing-safe comparison can avoid leaking information through comparison timing, but the check does not cryptographically prove the request came from Meraki or prevent replay of a captured valid payload. Use HTTPS to protect the secret in transit, and consider additional controls such as replay detection. Matching the device serial against your inventory only shows that the identifier looks familiar, since a forged alert can copy it. Checking for an alert type, organization ID and serial tests message shape rather than sender identity. A source-address allowlist is not a substitute for checking the configured secret. The secret is optional, and payload templates can affect the fields sent, so confirm what your dashboard actually sends. Practical check: replay an alert with a wrong secret and verify that your handler rejects it.