T09 · Insecure Skill Coding Practices
- Location
SKILL.md:454- Finding
Unrestricted Forwarding of Sensitive Webhook Payloads and Headers
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 454–459
Vulnerability Type: Sensitive information transmitted to an external service
Risk Level: Hights // 3. Forward to Hookflo for alerting/logging (optional) await fetch(process.env.HOOKFLO_WEBHOOK_URL!, { method: 'POST', headers: { ...req.headers, 'Content-Type': 'application/json' }, body: req.body, });Technical Analysis
The documented proxy pattern forwards the complete raw webhook body and copies all inbound request headers to an external Hookflo endpoint. This exceeds the minimum data access needed for typical alerting because webhook payloads can contain personal, financial, account, or operational information, while inbound headers can contain authorization values, cookies, signatures, internal proxy metadata, tracing identifiers, and infrastructure details.
Spreading
req.headersinto an outbound request provides no explicit security boundary or allowlist. Consequently, any sensitive header introduced by the provider, an upstream proxy, middleware, or another trusted component can cross that boundary unintentionally. Forwarding the unmodified body similarly prevents field-level data minimization or redaction.The destination comes from
HOOKFLO_WEBHOOK_URL, but the example does not validate that it uses HTTPS or belongs to an approved Hookflo hostname. A deployment mistake or compromised configuration could therefore direct the forwarded information to an unintended recipient.This is an unsafe documented implementation pattern rather than evidence of covert exfiltration: forwarding is labeled optional and supports the declared logging and alerting functionality. Nevertheless, forwarding every header and payload field is broader than necessary for that functionality.
Attack Path
- A webhook provider sends a correctly signed event containing sensitive payload fields or headers.
- The server verifies the event wi ...[truncated 1607 chars]
- Remediation
View remediation
Remediation Suggestions
- Replace the blanket header spread with a strict allowlist containing only headers explicitly required by the destination:
ts const outboundHeaders: Record<string, string> = { 'Content-Type': 'application/json', }; - Never forward
authorization,cookie, internal proxy headers, unrelated provider signatures, or other credentials unless a documented protocol strictly requires them. - Construct a minimized outbound event containing only the fields required for alerts. Redact personal, financial, secret, and authentication data before transmission.
- Require explicit user consent before enabling third-party forwarding and document what data Hookflo receives, how it is retained, and which compliance obligations apply.
- Parse and validate
HOOKFLO_WEBHOOK_URLbefore use. Require HTTPS and enforce an approved destination-host allowlist rather than accepting an arbitrary environment-provided hostname. - Use a dedicated outbound authentication credential instead of reusing inbound provider credentials or signatures.
- Add request timeouts, bounded payload sizes, error handling, and retry controls. Alerting failures should not cause repeated processing of an otherwise valid webhook.
- Preserve replay defenses and implement event-id-based idempotency before local processing or forwarding.
- Update the documentation to mark forwarding as a data-sharing operation and provide a privacy-preserving example by default.
- Replace the blanket header spread with a strict allowlist containing only headers explicitly required by the destination: