T09 · Insecure Skill Coding Practices
Error
- Location
- webhooks.md:259
- Finding
- Unrestricted Retention and Forwarding of Complete Webhook Payloads<![CDATA[ ## Vulnerability Details **File Location**: `webhooks.md:259-268` and `webhooks.md:319-326` **Vulnerability Type**: Sensitive-data exposure through excessive logging and email forwarding **Risk Level**: High ### Vulnerable Code ```text ### 3. Log Everything Action: Create Google Sheets Row Spreadsheet: Webhook Logs Data: Timestamp: {{zap_meta_human_now}} Zap ID: {{zap_meta_id}} Trigger Data: {{trigger.raw_body}} Response: {{webhook_response}} ``` ```text ### Webhook to Email Trigger: Catch Hook → Send Email: To: alerts@company.com Subject: New webhook: {{trigger.event}} Body: {{trigger.raw_body}} ``` ### Technical Analysis The Skill recommends storing the complete webhook request body and response in Google Sheets and forwarding the complete request body through email. Webhook payloads can contain personal information, payment or order details, access tokens, session identifiers, authorization headers, password-reset links, uploaded content, internal identifiers, and application-specific secrets. This behavior violates data-minimization and least-privilege principles. Operational diagnosis generally requires an event identifier, timestamp, result status, and sanitized error details—not unrestricted copies of all request and response data. Google Sheets and email may also have broader access, longer retention, forwarding, synchronization, and backup behavior than the source application. The instructions conflict with the Skill's security statement that connected applications receive only explicitly mapped data. Although `{{trigger.raw_body}}` is technically an explicit mapping, it indiscriminately maps every payload field and therefore defeats meaningful field-level minimization. ### Attack Path 1. An attacker or compromised upstream service submits a webhook containing sensitive values in the request body. 2. The Zap receives the payload through a Catch Hook or Catch Raw Hook. 3. The workflow follows the documented “Log Everyth ...[truncated 1072 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Replace “Log Everything” with an explicit allowlist of operational fields, such as: - Event ID - Event type - Receipt timestamp - Processing status - HTTP status code - Sanitized error category 2. Never log or email raw request bodies by default. 3. Recursively redact fields matching sensitive names, including `authorization`, `cookie`, `token`, `secret`, `password`, `api_key`, `session`, and `credential`. 4. Require explicit user confirmation before forwarding payload content to another service. 5. Separate diagnostic metadata from business payloads and apply role-based access controls. 6. Define retention periods and automatically delete old webhook logs. 7. Avoid email for sensitive diagnostic content; send a sanitized event identifier and provide a restricted audit-system link instead. 8. Add payload-size limits and schema validation before processing or recording webhook data. 9. Document that webhook responses may also contain secrets and must undergo the same redaction process. ]]>