Missing Input Validation

External input flows into sensitive operations without being checked for type, shape, range, or sanitization.

Security Scan

This is an instruction-only guidance skill about input validation; its content, requirements, and scope are coherent and proportional to its stated purpose.

Purpose & Capability

Name and description match the SKILL.md guidance. The skill requests no binaries, env vars, installs, or file access — appropriate for a documentation/teaching skill.

Instruction Scope

SKILL.md contains high-level developer guidance on validating external inputs and avoiding injection; it does not instruct the agent to read files, access credentials, or contact external endpoints. One recommendation—to include unexpected values in error messages to aid debugging—could inadvertently encourage logging sensitive inputs; treat that advice carefully.

Install Mechanism

No install spec and no code files — lowest-risk, nothing is written to disk or executed by the skill itself.

Credentials

The skill requests no environment variables, no credentials, and no config paths; this is proportional for a purely instructional skill.

Persistence & Privilege

always is false and model invocation is allowed (default). As an instruction-only skill this presents no additional privilege beyond normal agent behavior.

Assessment

This skill is safe and simply provides best-practice guidance on input validation. It doesn't install code or request secrets. Before acting on its advice, avoid copying sensitive input values into logs or error messages (the SKILL.md suggests including unexpected values for debugging, which can leak secrets). Use strong schema validators (Zod, Pydantic, etc.) and prefer parameterized APIs rather than string concatenation. If you plan to apply the guidance automatically (e.g., via code-generation), review resulting code to ensure it doesn't accidentally echo or store sensitive inputs.

Any data from outside the process — HTTP request bodies, CLI args, file contents, third-party API responses, user messages — should be treated as untrusted until proven otherwise. Code that uses it directly opens injection, crash, and security paths.

Symptoms

• HTTP handler uses request.body.x with no type check.
• CLI flag value passed straight into exec, SQL, or a file path.
• Third-party API response fields accessed without confirming they exist.
• Numeric input used in array indexing or arithmetic with no bounds check.
• String input concatenated into SQL, shell commands, or file paths.

What to do

• At every trust boundary, validate type, shape, and range before using the value. Reject early with a clear error message.
• For structured payloads, use a schema validator (Zod, Pydantic, ArkType, etc.) — don't hand-write "if field exists".
• For values used in SQL, shell, or file paths, use parameterized queries, execFile with an argv array, or explicit path joins — never string concatenation.
• When an invariant is checked, include the unexpected value in the error so debugging is possible.
• Third-party responses are not trustworthy. Validate them the same way you'd validate user input.