testing-api-authentication-weaknesses

HIGH W007: Insecure credential handling detected in skill instructions.

• Insecure credential handling detected (high risk: 1.00). The prompt's workflow captures and prints authentication tokens and cookies, inserts actual token values into Authorization headers and query parameters, and even outputs recovered secrets (e.g., discovered JWT HMAC secrets) verbatim in reports, so an LLM executing it would need to handle and emit secret values directly.

CRITICAL E006: Malicious code pattern detected in skill scripts.

• Malicious code pattern detected (high risk: 0.90). The content contains explicit offensive tooling and workflows for credential theft and account takeover (JWT alg:none forgery, payload tampering to escalate privileges, HMAC secret brute-forcing, credential stuffing/account enumeration) which are high-risk, dual-use capabilities that can be readily abused if used without authorization.

MEDIUM W011: Third-party content exposure detected (indirect prompt injection risk).

• Third-party content exposure detected (high risk: 0.90). The skill's workflow and code (SKILL.md Steps 1–6 and scripts/agent.py) make HTTP requests to an arbitrary BASE_URL and ingest response bodies, headers, cookies and JWTs from target endpoints (e.g., login responses, /swagger.json, /users/me), then parse those untrusted, external responses to drive further tests and actions (token analysis, forging, brute-force attempts), so third-party content can materially influence agent behavior.

HIGH W008: Secret detected in skill content (API keys, tokens, passwords).

• Secret detected (high risk: 1.00). I flagged the document because it contains one explicit, reusable credential string: "company-jwt-secret-2023" — presented as the recovered HMAC secret used to forge JWTs. It is a literal secret in the scenario/attack chain and therefore a hardcoded credential in the docs (usable to demonstrate the issue).

I did NOT flag the many obvious examples/placeholders and low-entropy test values:

• "TestPass123!" (example login password) — low-entropy example/test data.
• The COMMON_JWT_SECRETS list entries (e.g., "secret", "password", "jwt_secret", "your-256-bit-secret", "my-secret-key", etc.) — these are example/weak secrets or placeholders used for demonstration and testing, not unique high-entropy credentials to be treated as leaked production secrets.
• Environment placeholders like BASE_URL, "https://target-api.example.com/api/v1", and names like YOUR_API_KEY or sk-xxxx (none present as real keys) — documentation placeholders.
• Other simple/example passwords in weak_passwords and comments (e.g., "password", "12345678", "Password1") — intentionally weak/test inputs and excluded by the rules.

Although "company-jwt-secret-2023" is not a long random string, it is a specific literal secret used in the scenario to demonstrate an exploit, so it meets the requirement of being a directly present, usable credential in the documentation and should be treated as a hardcoded secret.