A retail chain registered a Meraki webhook that posts switch and access point alerts to an internal receiver. The team set a shared secret at registration, but the endpoint sits on a public URL where health checks omit the shared-secret header, the comparison must resist timing measurement, and unauthenticated bodies must stay out of the parser. Which validation sequence meets all three requirements?
Select an answer to reveal the explanation.
Short Explanation
First, check that the shared-secret header is present and return 401 if it’s missing; then compare it in constant time and reject before parsing the body. It’s like a door clerk checking each ID at the same steady pace, so attackers can’t use response timing to guess your secret.
Full Explanation
Meraki attaches the shared secret to each delivery so the receiver can prove the request came from the service you registered instead of from anyone who found the public URL. Checking that the header exists first turns an absent credential into an ordinary 401, which is what a health check or a scanner should get instead of a stack trace. A constant-time comparison helps prevent timing measurements from revealing information about how much of a secret an attacker has guessed. Doing that comparison before parsing means an unauthenticated body never reaches your JSON parser, your database, or your logs. Ordinary string equality may stop at the first mismatch, so reply timing can reveal information about a guessed secret. Parsing and storing before validating is unauthenticated input processing, so untrusted data reaches everything downstream. Skipping the presence check can cause an error when the code tries to compare a missing header, potentially exposing a server error. Exam caveat: header names and recommended status codes live in current documentation, so confirm them instead of memorising. Practical check: send one valid request, one with a wrong secret, and one with no secret header, then confirm clean rejections and no traceback.