What is a webhook?
A webhook is an event notification sent over HTTP. A receiving system registers a URL with a source system and picks the events it cares about. When one occurs, such as a new alert, a code push, a payment or a closed ticket, the source sends an HTTP POST to that URL carrying the event details, usually as JSON. The receiver hears about the event within seconds and can act on it at once. Webhooks are sometimes called reverse APIs, because the source calls the receiver instead of the receiver asking the source.
Webhook vs. API polling
With an ordinary API, the client decides when to ask. A SOAR platform might call an EDR's API every five minutes to check for new detections, which wastes requests when nothing has happened and adds delay when something has. A webhook pushes the event the moment it occurs. Most integrations use both: the webhook announces the event, and the receiver then calls the source's API to fetch details or take an action.
Example: a scanner finding delivered by webhook
A vulnerability scanner notifies a ticketing system when it finds a critical issue. The request body is a short JSON document, such as {"event":"finding.created","severity":"critical","host":"web-prod-02","cve":"CVE-2021-44228"}, sent with a header that carries a signature of that body. The ticketing system checks the signature, opens a priority ticket for the server's owner and answers with a 200 status so the scanner knows the delivery worked. Senders typically retry deliveries that fail or time out, so the same event can arrive more than once.
Securing webhooks
- Verify every delivery. The source computes an HMAC over the raw request body with a secret both sides share and sends it in a header; the receiver repeats the calculation and drops any request whose value differs. An unsigned endpoint accepts forged events from anyone who finds the address.
- Block replays. Sign a timestamp along with the body, refuse requests that are too old, and record event IDs so a duplicate isn't processed twice.
- Use HTTPS only, and keep the signing secret in a vault with a rotation plan.
- Treat the URL as a secret when it carries its own token, as many chat-channel webhooks do. A leaked URL lets anyone post to the channel, which is why secrets scanners look for them.
- Validate the payload against the expected format and act only on fields you expect.
- Restrict destinations if your own service lets customers register webhook URLs. Otherwise an attacker can point one at an internal address, such as a cloud metadata endpoint, and turn your sender into a server-side request forgery tool.
Webhooks in security operations
Security teams use webhooks to link tools without waiting on schedules: an EDR posts detections to a SOAR platform, a code host tells the CI/CD system about each push, a SIEM sends high-severity alerts to the on-call chat channel, and a cloud provider reports configuration changes to a posture management tool. Each link is also something to monitor. A webhook that silently stops arriving, after a certificate expires or a secret is rotated on only one side, means alerts stop flowing with no error on the receiving end.
Webhook on the CompTIA Security+ exam
Webhooks are taught under SY0-801 objective 4.6, as one of the two mechanisms, with APIs, that connect security tools into automated workflows. When a question needs one tool to hear about an event within seconds instead of checking on a timer, think webhook. A worry that someone could send fake events to an integration and trigger real responses points to signature verification with a shared secret plus a timestamp check. Distractors include keeping the URL private or moving it to an unusual port, which are security through obscurity, and replacing the webhook with a slower batch export.