T09 · Insecure Skill Coding Practices
Error
- Location
- index.js:26
- Finding
- Payment Enforcement Is Completely Bypassed<![CDATA[ ## Vulnerability Details **File Location**: `index.js:26-31` and `server.js:27-32` **Vulnerability Type**: Missing payment authorization and verification **Risk Level**: High ### Vulnerable Code ```js // Middleware to check payment (simplified - returns 402 if no payment) function requirePayment(req, res, next) { const hasPayment = req.headers['x-payment'] || req.headers['payment-signature'] // For demo, allow requests through - in production verify payment next() } ``` The alternate server implementation contains the same issue: ```js // Check for payment header (simplified) function checkPayment(req, res, next) { const payment = req.headers['x-payment'] || req.headers['payment-signature'] // For now, allow free access - add payment verification later next() } ``` These ineffective middleware functions are attached to the paid endpoints: ```js app.get('/api/status', requirePayment, (req, res) => { ``` ```js app.get('/api/geocode', requirePayment, async (req, res) => { ``` ```js app.get('/api/weather', requirePayment, async (req, res) => { ``` ### Technical Analysis Both implementations read a possible payment header but never inspect or validate its value. They unconditionally invoke `next()`, including when neither payment header exists. Consequently, the application never calls its payment-required helper and never returns the advertised HTTP 402 response. A secure x402 implementation must validate the payment proof cryptographically and confirm the expected network, asset, amount, recipient, expiration, and replay status. Merely checking for a header would also be insufficient because an attacker could supply an arbitrary string. ### Attack Path 1. An attacker sends a request without an `x-payment` or `payment-signature` header: ```http GET /api/geocode?q=London HTTP/1.1 Host: target.example ``` 2. `requirePayment` reads two undefined header values. 3. The middleware unconditionally calls `next()`. 4. The endpoi ...[truncated 684 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions - Reject requests that do not contain a valid payment proof and return the existing HTTP 402 payment challenge. - Use a maintained x402 verification library or a trusted payment facilitator rather than implementing signature validation informally. - Cryptographically verify: - Signature authenticity and signer identity. - Base network identifier. - Exact USDC token contract. - Required amount and recipient. - Proof expiration or validity window. - Nonce or transaction uniqueness to prevent replay. - Final payment or settlement status where required by the protocol. - Call `next()` only after all verification steps succeed. - Apply the same authorization implementation consistently to every paid route. - Add per-client rate limiting, request timeouts, and monitoring to reduce abuse. - Add automated tests proving that missing, malformed, underpaid, expired, and replayed proofs are rejected. ]]>