Webhook Security Testing is an important part of modern API security because webhooks allow external applications and services to send event notifications directly to another system. Businesses use them to process payments, update customer records, trigger background jobs, synchronize data, and automate workflows.
Unlike traditional API communication, where an application usually sends a request to another service, webhooks allow a provider to initiate an HTTP request when a particular event occurs. For example, a payment gateway may send a webhook to an online store after a successful transaction.
This integration makes applications more responsive, but it also creates security risks. An attacker may attempt to forge webhook requests, reuse previously captured events, manipulate payloads, or exploit the trust an application places in an external service.
A secure webhook implementation must verify the sender, validate the request signature, prevent replay attacks, and enforce clear trust boundaries. In this guide, we will explore how security professionals can test these controls, identify common webhook vulnerabilities, and recommend practical remediation measures.
What Is a Webhook?
A webhook is an HTTP callback that allows one application to notify another application when a specific event occurs.
Instead of repeatedly requesting information from an external service, an application receives an HTTP request when an event takes place.
For example, consider an e-commerce platform integrated with a payment gateway.
The process may look like this:
- A customer completes a payment.
- The payment gateway processes the transaction.
- The gateway generates a payment event.
- It sends an HTTP POST request to the store’s webhook endpoint.
- The store verifies the request.
- The application updates the order status.
A simplified webhook request might look like this:
POST /webhooks/payment HTTP/1.1
Host: shop.example.com
Content-Type: application/json
X-Webhook-Signature: sha256=example_signature
X-Webhook-Timestamp: 1793623145
{
"event": "payment.completed",
"order_id": "ORD-10021",
"amount": 2500,
"currency": "INR"
}The receiving application should not automatically trust this request simply because it contains payment information.
An attacker could create a similar HTTP request and attempt to send it directly to the endpoint.
This is why webhook authentication and request validation are essential.
Why Is Webhook Security Testing Important?
Webhooks often connect systems that have different security controls, authentication mechanisms, and levels of trust.
A weakness in one integration can affect the application receiving the event.
For example, if an application accepts an unsigned payment webhook, an attacker might attempt to submit a forged event that changes an order’s status without completing the actual payment.
Several security risks make webhook testing important.
1. Forged Webhook Requests
If an endpoint does not properly authenticate incoming requests, an attacker may send a fake event.
The application might process it as a legitimate notification from the external provider.
This can lead to unauthorized actions, such as changing account details, activating subscriptions, or updating payment records.
2. Replay Attacks
An attacker who captures a valid webhook request may attempt to send the same request again.
If the application does not check timestamps, event identifiers, or duplicate processing, it may perform the same action multiple times.
For example, a repeated payment notification could cause incorrect order processing if the application does not handle duplicate events safely.
3. Payload Manipulation
An attacker may modify webhook fields such as:
- User ID.
- Order ID.
- Payment status.
- Transaction amount.
- Account identifier.
- Event type.
- Subscription status.
Without proper signature verification, the receiving application may process manipulated information.
4. Trust Boundary Violations
A webhook provider is an external system. Its requests cross a trust boundary when they enter the receiving organization’s infrastructure.
If the application trusts every incoming request without validating its origin and contents, attackers may exploit that assumption.
5. Server-Side Request Forgery and Unsafe Event Processing
Some webhook systems allow administrators or users to configure destination URLs.
If the application fetches or forwards requests to arbitrary destinations without proper restrictions, it may introduce server-side request forgery (SSRF) risks.
Webhook handlers may also process URLs, file references, or other event data in unsafe ways.
These risks should be evaluated according to the application’s architecture.
Common Webhook Security Vulnerabilities
Security professionals should understand the weaknesses that can affect webhook integrations before starting a penetration test.
1. Missing Signature Validation
Signature validation confirms that a webhook request was generated by a party possessing the expected signing secret.
If the receiving application does not verify the signature, it may accept requests created by unauthorized users.
For example, an attacker may send:
POST /webhooks/payment HTTP/1.1
Host: shop.example.com
Content-Type: application/json
{
"event": "payment.completed",
"order_id": "ORD-10021"
}If the endpoint processes this request without authentication, an attacker may be able to trigger unauthorized business actions.
Security recommendation: Require signature verification for every protected webhook event. Reject missing or invalid signatures before processing the payload.
2. Weak HMAC Implementation
Many webhook providers use a keyed-hash message authentication code (HMAC) to sign request data.
HMAC combines a cryptographic hash function with a shared secret.
However, incorrect implementation can weaken the protection.
Common mistakes include:
- Using a weak or predictable signing secret.
- Comparing signatures incorrectly.
- Signing a different representation of the payload from the one received.
- Using an outdated or inappropriate hash algorithm.
- Accepting malformed signatures.
- Logging signing secrets.
Security recommendation: Follow the provider’s documented signature scheme, use a strong secret, and compare signatures using a constant-time comparison function.
3. Replay Attacks
Replay attacks occur when an attacker reuses a previously valid request.
Suppose a payment provider sends a legitimate event:
{
"event_id": "evt_90021",
"event": "payment.completed",
"order_id": "ORD-10021"
}An attacker captures the request and sends it again later.
If the application processes the duplicate event as a new transaction, it may repeat the associated action.
Security recommendation: Validate signed timestamps, enforce an acceptable time window, and maintain event identifiers or another deduplication mechanism to prevent repeated processing.
4. Missing Timestamp Validation
A valid signature alone does not necessarily prevent replay attacks.
An attacker may reuse a previously captured request if the application never checks when it was generated.
A signed timestamp helps the receiving application determine whether the request is sufficiently recent.
However, the timestamp must be included in the signed data. Otherwise, an attacker may modify it without invalidating the signature.
Security recommendation: Verify the timestamp as part of the signature validation process and reject requests outside the configured time window.
5. Insecure Trust Boundaries
A webhook endpoint should treat incoming requests as untrusted until the required verification steps are complete.
Common mistakes include:
- Trusting a request because it comes from a known IP address.
- Assuming HTTPS alone authenticates the sender.
- Trusting user IDs supplied in the payload.
- Processing events before signature verification.
- Allowing unverified events to trigger privileged internal actions.
Security recommendation: Verify the sender, validate the payload, and independently enforce authorization before allowing the event to trigger sensitive operations.
6. Insufficient Authorization Checks
A valid webhook signature confirms that the request was signed using the expected secret. It does not automatically prove that every action described in the payload is authorized.
For example, a payment provider may legitimately notify an application about a payment event. However, the receiving application must still verify that the order belongs to the expected customer and that the event is valid for the order’s current state.
Security recommendation: Apply business-level authorization and state validation after cryptographic verification.
How Webhook Signature Validation Works
Signature validation is one of the most important security controls in webhook implementations.
It helps the receiving application verify that a request was generated by a party possessing the correct signing secret and that the signed content has not been modified.
A common implementation uses HMAC-SHA256.
Understanding HMAC-SHA256
HMAC-SHA256 uses:
- A shared secret.
- The request content or provider-defined signing message.
- The SHA-256 hashing algorithm.
The sender calculates a signature using the secret and sends it with the request.
The receiver independently calculates the expected signature using the same secret and the appropriate request data.
If the signatures match, the request passes the cryptographic integrity check.
A simplified representation is:
Signature = HMAC-SHA256(secret, signed_message)The exact signed message depends on the webhook provider.
Some providers sign only the raw request body. Others include a timestamp, request identifier, or additional fields.
Always follow the provider’s documented format.
Testing Signature Validation
During an authorized security assessment, testers should evaluate several conditions.
Test 1: Missing Signature
Remove the signature header and send the request to the test endpoint.
Expected result: The application rejects the request.
Test 2: Invalid Signature
Replace the original signature with a random or incorrect value.
Expected result: The application rejects the request without triggering the associated business action.
Test 3: Modified Payload
Change a signed field, such as the order ID or payment status, without generating a new valid signature.
Expected result: Signature verification fails.
Test 4: Malformed Signature
Test an empty, truncated, incorrectly formatted, or unexpected signature value.
Expected result: The application handles the input safely and rejects the request.
Test 5: Valid Signature
Send an authorized request with the correct signature and expected payload.
Expected result: The application accepts the request and processes the event according to its business rules.
Important Implementation Detail: Verify the Raw Request Body
One common implementation mistake occurs when the application parses JSON before calculating the signature.
For example, these JSON representations may contain the same logical information:
{"event":"payment.completed","amount":2500}{
"event": "payment.completed",
"amount": 2500
}However, their raw byte sequences are different.
If the provider signs the raw body, parsing and reserializing the JSON before verification can produce a different signature.
The receiving application should preserve the raw request bytes and verify the signature against the exact data specified by the provider.
How to Test Webhook Replay Attacks
Replay testing checks whether an application accepts a previously valid request more than once or outside the permitted time window.
This is especially important for payment notifications, account updates, subscription events, and automated business workflows.
Step 1: Capture a Valid Webhook Request
In an authorized test environment, capture a legitimate webhook request using an HTTP proxy such as Burp Suite.
Record the relevant information:
- Request method.
- Webhook endpoint.
- Event identifier.
- Timestamp.
- Signature header.
- Request body.
- Resulting application behavior.
Step 2: Resend the Original Request
Replay the exact same request through the testing proxy.
Do not modify the body, timestamp, or signature during the initial duplicate-delivery test.
Step 3: Observe the Application Response
Check whether the application processes the event again.
A secure implementation should recognize an already processed event and prevent duplicate business operations.
The endpoint may return a successful HTTP response for a duplicate event to prevent unnecessary provider retries, but it should not repeat the protected business action.
Step 4: Test an Expired Timestamp
In a controlled test environment, use an old signed request.
If the signature covers the timestamp, changing the timestamp without generating a valid signature should cause verification to fail.
Expected result: The application rejects the expired or invalid request.
Step 5: Verify Event Deduplication
Check whether the application records processed event identifiers or uses an equivalent reliable mechanism.
The deduplication record should be stored in a way that prevents concurrent duplicate requests from triggering the same operation.
Important Consideration
Timestamp validation and idempotency solve different problems.
Timestamp validation limits how old a signed request can be.
Idempotency prevents the same event from causing the same business action multiple times.
A robust webhook implementation generally needs both.
Understanding Trust Boundaries in Webhook Integrations
A trust boundary separates systems, users, or components with different security privileges or levels of trust.
Webhook integrations create several trust boundaries because external services communicate with internal application components.
1. External Provider to Webhook Endpoint
The first boundary exists between the webhook provider and the organization’s public-facing endpoint.
The application must verify the request before trusting its contents.
Controls include:
- HTTPS.
- Signature validation.
- Timestamp verification.
- Request size limits.
- Content-type validation.
- Rate limiting where appropriate.
2. Webhook Endpoint to Internal Application
After receiving a valid request, the webhook handler may communicate with internal services, databases, or message queues.
The application should not allow the incoming event to bypass normal authorization checks.
For example, a webhook should not be able to update any customer account merely because the payload contains a customer ID.
3. Application to Database
Webhook data may eventually be stored in a database.
The application should validate values, use parameterized database queries, and enforce appropriate access controls.
This reduces risks such as SQL injection and unauthorized record modification.
4. Webhook Handler to Third-Party Services
Some webhook handlers trigger additional external requests.
For example, a payment event may cause an application to call an accounting service or notification provider.
The destination and credentials used for these requests should be controlled.
Avoid allowing untrusted webhook fields to determine arbitrary internal or external request destinations.
Practical Example: Testing a Payment Webhook
Consider an online store that uses an external payment gateway.
After a customer completes a payment, the gateway sends a payment.completed event to the store.
The store receives the request and updates the corresponding order status.
A penetration tester is asked to assess the webhook endpoint within an authorized scope.
Initial Request
The tester captures a legitimate payment event containing:
{
"event_id": "evt_7001",
"event": "payment.completed",
"order_id": "ORD-7001",
"amount": 2500,
"currency": "INR"
}The request includes a provider-generated signature and timestamp.
Security Test Cases
Test 1: Remove the Signature
The tester removes the signature header.
Expected result: The application rejects the request and does not update the order.
Test 2: Modify the Amount
The tester changes the amount from 2500 to 500.
Expected result: The modified request fails signature verification.
Test 3: Replay the Valid Request
The tester sends the same valid event again.
Expected result: The application recognizes the duplicate event and does not repeat the payment-related business action.
Test 4: Use an Expired Request
The tester submits an old signed request.
Expected result: The application rejects the request if it falls outside the configured timestamp window.
Test 5: Change the Order Identifier
The tester modifies the order ID without generating a valid signature.
Expected result: The signature check fails. The application must also verify order ownership and payment state for valid events.
Reporting the Finding
If the endpoint accepts requests without signature validation and updates order status, the tester should document the issue with:
- Affected webhook endpoint.
- Missing or ineffective validation control.
- Authorized test account and test order.
- Original request and response.
- Modified request and response.
- Demonstrated business impact.
- Recommended remediation.
Testing should use non-production transactions or specifically authorized test records. Do not create unauthorized financial transactions or modify real customer orders.
Common Webhook Security Testing Tools
Security professionals use HTTP proxies, API testing tools, command-line utilities, and application logs to assess webhook security.
1. Burp Suite
Burp Suite is useful for intercepting, inspecting, modifying, and replaying HTTP requests.
During webhook testing, it can help assess:
- Signature validation.
- Request modification.
- Replay handling.
- HTTP response behavior.
- Authentication and authorization controls.
Official website: https://portswigger.net/burp
2. Postman
Postman helps testers create and send HTTP requests to webhook endpoints.
It can be used to test valid and invalid request formats, headers, payloads, and response handling.
Official website: https://www.postman.com/
3. OWASP ZAP
OWASP ZAP is an open-source web application security testing tool.
It can support HTTP request inspection, manual testing, and selected automated security checks.
Official website: https://www.zaproxy.org/
4. cURL
cURL is useful for sending controlled HTTP requests from the command line.
Example:
curl -X POST https://test.example.com/webhooks/payment \
-H "Content-Type: application/json" \
-H "X-Webhook-Signature: invalid_signature" \
-d '{"event":"payment.completed","order_id":"TEST-100"}'Use a test endpoint and authorized test data when performing these checks.
5. Application Logs and Monitoring
Logs are essential for confirming how the application handles webhook requests.
Security teams should review:
- Signature verification results.
- Timestamp validation failures.
- Duplicate event detection.
- Unexpected event types.
- Authorization failures.
- Processing errors.
Avoid recording signing secrets, full authentication tokens, or unnecessary sensitive customer data.
Best Practices for Securing Webhook Endpoints
Organizations should implement security controls at both the HTTP request level and the business logic level.
The following practices help reduce common webhook risks.
- Use HTTPS: Encrypt webhook traffic in transit and use valid TLS configurations.
- Verify signatures: Validate every protected request using the provider’s documented cryptographic scheme.
- Preserve the raw body: Verify the exact request bytes required by the signing protocol.
- Use strong secrets: Generate unpredictable signing secrets and store them in a secure secrets manager.
- Validate timestamps: Reject signed requests outside an appropriate time window.
- Implement idempotency: Prevent duplicate events from triggering repeated business operations.
- Enforce authorization: Verify that each event is permitted to affect the requested account, order, or resource.
- Validate event types: Process only expected event types and reject unsupported operations.
- Limit request sizes: Set reasonable payload size limits to reduce resource exhaustion risks.
- Rotate secrets safely: Support controlled secret rotation and follow provider-specific procedures for overlapping keys.
- Monitor failures: Log and alert on repeated invalid signatures, unusual request patterns, and replay attempts.
- Protect internal services: Do not allow untrusted payload fields to trigger arbitrary internal requests or privileged operations.
For webhook systems that support configurable destination URLs, apply strict URL validation and network egress controls. Block access to loopback, link-local, private, and other prohibited destinations where appropriate, and account for DNS resolution changes and redirects.
Webhook Security Testing Checklist
A structured checklist helps penetration testers and developers assess webhook endpoints consistently.
| Test Area | What to Verify | Expected Secure Behavior |
|---|---|---|
| HTTPS | Transport encryption | Requests use valid HTTPS |
| Missing signature | Remove signature header | Request rejected |
| Invalid signature | Submit an incorrect signature | Request rejected |
| Payload modification | Change signed content | Signature verification fails |
| Raw body handling | Test different body formatting | Verification follows provider’s signing specification |
| Timestamp validation | Submit an expired signed request | Request rejected outside the allowed window |
| Replay protection | Resend an already processed event | Business action is not repeated |
| Event validation | Submit an unsupported event type | Event rejected or safely ignored |
| Authorization | Test access to unrelated records | Unauthorized changes are blocked |
| Input validation | Submit malformed or oversized payloads | Request handled safely |
| Secret management | Review storage and logging practices | Secrets are protected |
| Monitoring | Review security event logs | Failures and suspicious activity are recorded |
This checklist should be adapted to the provider’s webhook design and the application’s business requirements.
Relevant Standards and Security References
Several established resources can help developers and security professionals understand webhook security in the wider context of API and application security.
OWASP API Security Top 10
The OWASP API Security Top 10 covers important API security risks, including broken object-level authorization, broken authentication, unrestricted resource consumption, and security misconfiguration.
These risks are relevant when webhook handlers expose sensitive application functionality.
Reference: https://owasp.org/API-Security/
OWASP Web Security Testing Guide
The OWASP Web Security Testing Guide provides practical guidance for assessing web application security.
Its testing principles can support the assessment of authentication, authorization, input validation, and application behavior around webhook endpoints.
Reference: https://owasp.org/www-project-web-security-testing-guide/
RFC 2104: HMAC
RFC 2104 describes the HMAC construction used for message authentication with cryptographic hash functions.
It provides the technical foundation for many webhook signature implementations.
Reference: https://www.rfc-editor.org/rfc/rfc2104
RFC 9421: HTTP Message Signatures
RFC 9421 defines a standard approach for creating and verifying signatures over HTTP message components.
It is useful background for understanding HTTP message integrity and signature-based authentication designs.
Reference: https://www.rfc-editor.org/rfc/rfc9421
OWASP Server-Side Request Forgery Prevention Cheat Sheet
This guidance is useful when webhook functionality accepts destination URLs or makes server-side requests based on external input.
Frequently Asked Questions (FAQs)
1. What is webhook security testing?
Webhook security testing is the process of evaluating webhook endpoints for weaknesses in authentication, signature verification, replay protection, authorization, input validation, and trust boundary enforcement. It helps ensure that applications process only legitimate and authorized events.
2. Why is webhook signature validation important?
Signature validation helps verify that a request was generated by a party possessing the expected signing secret and that the signed content has not been modified. Without it, an application may accept forged requests and perform unauthorized actions.
3. What is a webhook replay attack?
A webhook replay attack occurs when an attacker captures a previously valid webhook request and sends it again. If the receiving application does not validate timestamps or prevent duplicate event processing, the same business action may occur more than once.
4. How can developers prevent webhook replay attacks?
Developers should validate signed timestamps, enforce an acceptable request time window, and maintain event identifiers or another reliable deduplication mechanism. Idempotent processing should ensure that duplicate events do not repeat sensitive business operations.
5. Is HTTPS enough to secure a webhook?
No. HTTPS protects data in transit, but it does not independently prove that a request was generated by an authorized webhook provider. Applications should also validate signatures, timestamps, event contents, and business-level authorization.
6. What is the difference between HMAC and encryption?
HMAC provides message authentication and integrity. It helps verify that signed content has not been modified by someone who does not possess the secret. Encryption protects confidentiality by making information unreadable to unauthorized parties. HMAC does not encrypt the webhook payload.
7. Which tools are useful for webhook security testing?
Common tools include Burp Suite, Postman, OWASP ZAP, and cURL. Application logs and monitoring platforms are also useful for verifying signature failures, replay detection, duplicate processing, and webhook handler behavior.
8. Can webhook signature validation prevent all webhook attacks?
No. Signature validation is an important control, but it does not prevent every security issue. Applications must also handle replay attacks, enforce authorization, validate event state, restrict resource usage, protect secrets, and secure trust boundaries.
Conclusion
Webhooks make communication between applications faster and more efficient, but they also introduce security risks when external requests are trusted without proper verification.
Effective webhook security testing should cover signature validation, HMAC implementation, timestamp verification, replay protection, idempotency, authorization, input validation, and trust boundary enforcement.
Security professionals should test both cryptographic controls and the business logic that processes incoming events. A valid signature does not automatically mean that every requested action is authorized or appropriate.
Organizations should combine secure implementation practices with regular testing, monitoring, and careful secret management.
At PentestHint, we aim to help cybersecurity professionals strengthen their knowledge of API security, vulnerability assessment, and penetration testing. Explore our cyber security labs to develop practical skills and understand how application security weaknesses can be identified and validated.
Remember: A webhook should never be trusted simply because it reaches your endpoint. Verify the signature, validate the event, prevent replay, and enforce authorization before taking action.
