ClawHub
Back to skill

Security audit

Payments

Security checks for vulnerabilities and agentic risk

Overview

This is a documentation-only payments skill with one unsafe logging recommendation users should avoid in production.

This skill is safe to install as reference material, but do not follow the raw webhook payload logging advice as written. Log only sanitized event IDs, event types, correlation IDs, and processing outcomes, and avoid storing full payment-provider payloads in production logs.

A.I.G

Vulnerability Patterns
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (1)

T09 · Insecure Skill Coding Practices

Warning
Location
integration.md:46
Finding

Raw Webhook Payload Logging May Expose Sensitive Customer and Payment Metadata

Content
View full analysis

Vulnerability Details

File Location: integration.md, lines 46–54
Vulnerability Type: Sensitive data exposure through insecure logging
Risk Level: Medium

Vulnerable Code Snippet:

plaintext
### Webhook Security

```plaintext
1. Verify webhook signature (provider-specific)
2. Use HTTPS endpoint
3. Return 200 quickly, process async if slow
4. Implement idempotency (handle duplicate events)
5. Log raw payloads for debugging
text

### Technical Analysis

The guidance explicitly recommends logging raw webhook payloads. Payment-provider webhook bodies can include customer identifiers, email addresses, billing information, invoice links, transaction details, subscription metadata, and other personal or commercially sensitive data.

Copying complete payloads into application or centralized logging systems expands the number of systems that hold this information. The recommendation does not require field-level redaction, data minimization, encryption, access restrictions, retention limits, or disabling raw logging in production. Consequently, an implementation following this advice may expose sensitive data to support personnel, third-party logging services, or an attacker who compromises the logging platform.

### Attack Path

1. A payment provider sends a legitimate, correctly signed webhook containing customer and transaction metadata.
2. The webhook endpoint follows the documented recommendation and records the complete raw payload.
3. The payload is forwarded to an application log, monitoring service, or centralized log aggregator.
4. The logging system has broader access permissions or longer retention than the payment-processing system.
5. A malicious insider, unauthorized user, or attacker who compromises the logging environment retrieves the stored webhook data.
6. The exposed metadata is used for privacy violations, customer profiling, targeted phishing, or transaction reconnaissance.


...[truncated 1179 chars]
Remediation
View remediation

Remediation Suggestions

Replace the raw-payload logging recommendation with a data-minimized logging policy:

  1. Log only operationally necessary fields, such as the provider event ID, event type, creation time, processing result, retry count, and internal correlation ID.
  2. Apply an allowlist-based sanitizer before any webhook data reaches logs; do not rely only on a denylist of known sensitive fields.
  3. Redact customer email addresses, billing details, addresses, invoice URLs, payment-method details, access tokens, signatures, and unnecessary metadata.
  4. Never log full card numbers, CVV/CVC values, secrets, authorization headers, or webhook signing secrets.
  5. Disable full-payload logging in production. If temporary diagnostic capture is unavoidable, require explicit authorization, short retention, encryption, and automatic deletion.
  6. Encrypt logs in transit and at rest, enforce least-privilege access, and audit access to payment-related log streams.
  7. Establish retention limits appropriate to operational and legal requirements.
  8. Add automated tests that submit payloads containing representative sensitive fields and verify that those fields never appear in emitted logs.

A safer replacement would be:

plaintext
1. Verify the webhook signature using the unmodified request body.
2. Use an HTTPS endpoint.
3. Return 200 quickly and process asynchronously when necessary.
4. Implement idempotent event processing.
5. Log only sanitized event IDs, event types, correlation IDs, and processing outcomes; never log complete production payloads.

SkillSpector

Vulnerability Patterns
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep

Static analysis

No suspicious patterns detected.