Webhook Spoofing Attack
How Webhook Spoofing Works
Webhook spoofing is a technique where attackers manipulate the source or content of webhook notifications to trick systems into accepting malicious data. Unlike traditional spoofing that might involve IP address manipulation, webhook spoofing exploits the trust relationships between systems that communicate via HTTP callbacks.
The attack typically follows this sequence:
- Discovery: Attacker identifies a webhook endpoint that accepts callbacks from external services
- Spoofing: Attacker crafts HTTP requests that mimic legitimate webhook notifications, often including forged headers or signatures
- Manipulation: Attacker modifies payload content to include malicious data or commands
- Exploitation: Target system processes the spoofed webhook and executes unintended actions
The core vulnerability lies in inadequate validation. Many webhook implementations trust the HTTP headers (like X-Webhook-Signature or X-Forwarded-For) without verifying their authenticity. Attackers exploit this by either guessing valid signatures or finding systems where signature verification is improperly implemented.
Webhook Spoofing Against APIs
When applied to API endpoints, webhook spoofing becomes particularly dangerous because APIs often serve as integration points between critical business systems. Here's how attackers weaponize this technique against APIs:
Signature Forgery: Many APIs use HMAC signatures to verify webhook authenticity. Attackers can bypass this by:
- Stealing valid signing keys through other vulnerabilities
- Brute-forcing weak signature algorithms
- Exploiting timing attacks to guess valid signatures
Header Manipulation: APIs often rely on custom headers for routing or authentication. Attackers can:
- Set X-Forwarded-For headers to bypass IP restrictions
- Modify X-Original-URL headers to access restricted endpoints
- Spoof X-API-Key headers when validation is insufficient
Payload Injection: The actual webhook payload can contain malicious instructions:
POST /api/webhook HTTP/1.1
Host: target.com
Content-Type: application/json
X-Webhook-Signature: forged-signature
{
"event": "user.created",
"data": {
"id": 999,
"role": "admin",
"permissions": ["*"],
"email": "[email protected]"
}
}Real-world examples include the 2019 Travis CI incident where attackers could trigger builds by spoofing webhook notifications, and various SaaS platforms that have suffered data exfiltration through manipulated webhook callbacks.
Detection & Prevention
Detecting webhook spoofing requires a multi-layered approach that verifies both the source and content of webhook notifications. Here are proven strategies:
Signature Verification: Always use strong cryptographic signatures with secret keys that are:
- Rotated regularly
- Stored securely (never in code or client-side)
- Verified using constant-time comparison functions
Source Validation: Verify the actual origin of webhook requests:
// Example: Verify webhook source using IP allowlisting
const allowedSources = [
'192.168.1.0/24', // Internal network
'203.0.113.0/24', // Vendor IP range
'2001:db8::/32' // IPv6 range
];
function isValidWebhookSource(req) {
const clientIP = req.ip || req.connection.remoteAddress;
return allowedSources.some(range =>
ip.cidrSubnet(range).contains(clientIP)
);
}Payload Integrity: Validate webhook content against expected schemas:
const webhookSchema = {
type: 'object',
properties: {
event: { type: 'string', enum: ['user.created', 'payment.received'] },
data: {
type: 'object',
properties: {
id: { type: 'integer' },
role: { type: 'string', enum: ['user', 'admin'] },
permissions: { type: 'array', items: { type: 'string' } }
},
required: ['id', 'role']
}
},
required: ['event', 'data']
};
function validateWebhookPayload(payload) {
const { error } = validate(webhookSchema, payload);
if (error) {
throw new Error(`Invalid webhook payload: ${error.message}`);
}
}Rate Limiting: Implement rate limits per source IP or webhook key to prevent brute-force signature attacks.
Logging & Monitoring: Track webhook patterns and flag anomalies:
const webhookLog = {
sourceIP: req.ip,
signature: req.headers['x-webhook-signature'],
event: payload.event,
timestamp: Date.now(),
success: true
};
// Alert on suspicious patterns
if (isSuspiciousPattern(webhookLog)) {
notifySecurityTeam(webhookLog);
}Tools like middleBrick can help detect webhook spoofing vulnerabilities by scanning your API endpoints for missing signature verification, weak cryptographic implementations, and inadequate source validation. The scanner tests your webhook endpoints with crafted payloads to identify if they accept spoofed requests, providing specific remediation guidance for each finding.
Frequently Asked Questions
How can I tell if my webhook implementation is vulnerable to spoofing?
Test your webhook endpoint by attempting to send requests with modified headers, forged signatures, and unexpected payload structures. If your system processes these requests without validation errors, you have a vulnerability. middleBrick can automate this testing by scanning your API and identifying missing authentication controls, weak signature verification, and improper header validation.
What's the difference between webhook spoofing and replay attacks?
Webhook spoofing involves creating fraudulent webhook notifications that appear to come from legitimate sources, while replay attacks involve capturing and resending valid webhook notifications. Spoofing is about impersonation (faking the source), while replay is about repetition (reusing valid data). Both require different prevention strategies: spoofing needs source validation and signature verification, while replay attacks need nonce values, timestamps, or sequence numbers to detect reused messages.