T09 · Insecure Skill Coding Practices
Error
- Location
- SKILL.md:454
- Finding
- Unrestricted Forwarding of Sensitive Webhook Payloads and Headers## Vulnerability Details **File Location**: `SKILL.md`, lines 454–459 **Vulnerability Type**: Sensitive information transmitted to an external service **Risk Level**: High ```ts // 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.headers` into 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 1. A webhook provider sends a correctly signed event containing sensitive payload fields or headers. 2. The server verifies the event wi ...[truncated 1607 chars]
- Remediation
- ## Remediation Suggestions 1. 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', }; ``` 2. Never forward `authorization`, `cookie`, internal proxy headers, unrelated provider signatures, or other credentials unless a documented protocol strictly requires them. 3. Construct a minimized outbound event containing only the fields required for alerts. Redact personal, financial, secret, and authentication data before transmission. 4. Require explicit user consent before enabling third-party forwarding and document what data Hookflo receives, how it is retained, and which compliance obligations apply. 5. Parse and validate `HOOKFLO_WEBHOOK_URL` before use. Require HTTPS and enforce an approved destination-host allowlist rather than accepting an arbitrary environment-provided hostname. 6. Use a dedicated outbound authentication credential instead of reusing inbound provider credentials or signatures. 7. Add request timeouts, bounded payload sizes, error handling, and retry controls. Alerting failures should not cause repeated processing of an otherwise valid webhook. 8. Preserve replay defenses and implement event-id-based idempotency before local processing or forwarding. 9. Update the documentation to mark forwarding as a data-sharing operation and provide a privacy-preserving example by default.