T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:37
- Finding
- Unbounded Live API Testing Against Unverified Targets<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 37–42; supplementary instructions at lines 57–61 and 105–117 **Vulnerability Type**: `T09: Insecure Skill Coding Practices` **Risk Level**: Medium ### Vulnerable Instructions ```markdown ### 2. Live Testing (MANDATORY) - Make ACTUAL HTTP requests to all modified endpoints - Test with real payloads, verify responses - Check error codes and edge cases - Verify backward compatibility with existing client contracts ``` Related instructions reinforce the unsafe behavior: ```markdown ## Before Declaring Stable All must be YES: - [ ] Made ACTUAL requests to modified endpoints? - [ ] Tested real payloads and verified responses? - [ ] Checked error codes and edge cases? - [ ] Verified backward compatibility? - [ ] Would bet reputation existing clients won't break? ``` ```markdown ## Priority Order 1. ACTUAL API testing with real requests/responses 2. Contract testing with consumer scenarios 3. Edge case and error validation 4. Backward compatibility through live testing 5. Clear migration paths with tested examples ## Bottom Line The user wants guarantees their systems won't break. Test the APIs. Every endpoint. Every scenario. No exceptions. ``` ### Technical Analysis The skill unconditionally requires active HTTP testing of every modified endpoint and calls for real payloads, malformed requests, large payloads, timeout testing, and all scenarios without exception. It does not require the agent to establish: - Explicit authorization to test the target. - Whether the target is a production, staging, or sandbox environment. - Whether an endpoint performs destructive or irreversible operations. - Target allowlisting or scope restrictions. - Request rate, concurrency, or payload-size limits. - Use of synthetic rather than sensitive production data. - User confirmation before state-changing requests. - Cleanup or rollback procedures. This is an insecure configuration because the skill conver ...[truncated 2255 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Require explicit confirmation that the target owner has authorized active security and compatibility testing. 2. Default all live tests to a dedicated staging or sandbox environment. Prohibit production testing unless the user explicitly identifies the environment and approves the exact operations. 3. Require an allowlist of schemes, hosts, ports, endpoint paths, and HTTP methods before issuing requests. 4. Classify endpoints by side effect. Do not automatically test destructive, financial, administrative, notification, provisioning, or irreversible operations. 5. Require separate user confirmation before each state-changing or potentially destructive test. 6. Replace “real payloads” with synthetic, anonymized, or redacted fixtures. Prohibit secrets, personal data, payment data, and production records unless explicitly authorized and necessary. 7. Establish conservative limits for request rate, concurrency, payload size, retries, and test duration. 8. Run malformed-input, oversized-payload, load, and timeout tests only in environments specifically approved for resilience testing. 9. Prefer contract-test harnesses, mocks, recorded fixtures, OpenAPI validation, and isolated consumer tests before making live requests. 10. Add rollback, cleanup, and audit-log requirements for any approved operation that changes server state. 11. Replace “Every endpoint. Every scenario. No exceptions.” with scope-aware language that permits the agent to skip unsafe tests and report them as requiring manual authorization. 12. Add a mandatory preflight checklist covering authorization, environment, credentials, data classification, endpoint side effects, test limits, and emergency stop procedures. ]]>