insecure-plugin-design

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.

Verification

Confirm the following properties hold (language-agnostic):

• Every tool input is constrained at the tool boundary by some concrete mechanism — JSON Schema keywords (maxLength/pattern/enum/additionalProperties: false), a typed enum or sealed class in the method signature, runtime regex/length validation at the top of the handler, or an allowlist lookup against a static set — before the value is used
• Authorization is enforced inside the tool handler itself against the invoking principal — not delegated to the LLM's judgment, not assumed from the caller, and not handled only by an outer framework layer
• File, path, or resource identifiers supplied by the LLM are canonicalized and verified to fall within an explicit allowed root or allowlist before any I/O — path traversal, symlink escape, and absolute-path injection are all rejected
• Each tool exposes the narrowest capability that satisfies its purpose — read, write, and destructive operations are separated into distinct tools/handlers rather than multiplexed behind a single action parameter
• Every tool invocation produces an audit record containing the invoking principal, the tool name, and the (sanitized) parameter values, written before the side-effecting operation returns

References

• CWE-284 (Improper Access Control)
• CWE-20 (Improper Input Validation)
• OWASP LLM07:2025 Insecure Plugin Design