testing-api-authentication-weaknesses

HIGH W007: Insecure credential handling detected in skill instructions.

• Insecure credential handling detected (high risk: 1.00). The prompt explicitly captures and prints JWTs, cookies, refresh tokens and even example secrets, and instructs embedding them verbatim in headers, URLs, and findings (e.g., Authorization: Bearer {token}, showing recovered secrets), which forces the LLM to handle/output secret values directly.

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.