soundcheck: Skill for Claude Code

Insecure Plugin Design (OWASP LLM07:2025)

What this checks

Prevents LLM tools and plugins from being abused via malicious or malformed inputs driven by prompt injection or jailbreaks. Unvalidated tool parameters let an attacker escalate from a chat window to arbitrary file access, command execution, or data exfiltration.

Vulnerable patterns

• Tool handler accepts an unconstrained string parameter (path, URL, query) with no allowlist, regex, or length cap
• Tool schema declares parameters with no enum, maxLength, pattern, or additionalProperties: false constraints
• Authorization decision delegated to the LLM rather than enforced inside the tool handler against the invoking principal
• Single tool multiplexes read, write, and delete behind an action parameter instead of separate handlers
• Tool invocation produces no audit record naming the principal, tool, and sanitized arguments

Fix immediately

Flag the vulnerable code and explain the risk. Translate the principles below to the audited file's language, tool-definition schema, and authorization framework — use that stack's documented validation and access-control APIs.

For each finding, establish these properties:

1. Every tool input is constrained at the tool boundary. JSON Schema keywords (maxLength, pattern, enum, additionalProperties: false), a typed enum or sealed class, runtime validation at the top of the handler, or an allowlist lookup — the goal is that a malformed value never reaches the handler body.
2. Authorization runs inside the handler against the invoking principal — not outsourced to the LLM's judgment, not inferred from the caller, not handled only by an outer framework layer. The LLM is an attacker in the threat model; it cannot be trusted to gate its own actions.
3. File and path identifiers are canonicalized and verified against an explicit root. Resolve the path, then check that the resolved target falls inside the allowed directory. Path traversal, symlink escape, and absolute-path injection all fail this check.
4. Tools expose the narrowest capability that satisfies their purpose. Read, write, and delete live in separate handlers, not multiplexed behind an action parameter. Narrow tools are easier to audit and harder to weaponize.
5. Every invocation produces an audit record containing the principal, the tool name, and sanitized parameters — written before the side-effecting operation returns.