输入验证（input-validation）是一项面向安全开发的实践技能，其核心目标是在每一个入口点验证并净化所有用户输入。资料明确指出，该技能覆盖路径遍历问题（标记为 Finding #2），并超越 SQL 注入范畴，延伸到 XSS、命令注入与数据完整性。
基本规则 资料强调的核心原则是：永远不要信任用户输入，必须始终在服务端验证类型、长度、格式与范围。
可防范的攻击向量 资料列出了若干攻击方式及其对应的验证修复思路。XSS 通过在渲染的 HTML 中注入 script 标签实现，修复方式为对输出进行 HTML 编码，并校验文本字段中不包含 HTML。路径遍历通过在文件路径中使用 ../../etc/passwd 实现，修复方式是白名单允许路径并拒绝 ..。命令注入通过 shell 命令中的 ; rm -rf / 实现，修复方式是绝不将用户输入传入 shell，而使用带参数数组的 spawn。SSRF 通过用户可控 URL 访问内部服务实现，修复方式是白名单允许域名并屏蔽私有 IP。原型污染通过在 JSON 键中使用 proto 实现，修复方式是剥离危险键并使用 Object.create(null)。文件上传滥用通过将 .php 文件伪装成图片上传实现，修复方式是校验 MIME 类型与魔术字节，而不仅仅是扩展名。
框架使用模式 资料给出了 Node.js 配合 Zod 的推荐做法：定义严格 schema，使用 z.string().email()、max()、min()、regex()、z.number().int().min().max()、z.enum() 等约束字段，并在 API 边界使用 safeParse 校验请求体；校验失败返回 400 及错误明细，成功则使用类型安全的校验结果。
针对路径遍历，资料给出了对比示例。错误做法是直接用 path.join 拼接用户提供的文件名并 sendFile；正确做法是先用 path.basename 剥离目录遍历，再用 path.resolve 解析绝对路径，并校验解析后的路径仍位于允许的上传目录内，否则返回 403。
针对 XSS，资料给出对比示例。错误做法是将用户输入直接拼入服务端渲染的 HTML；正确做法是使用 html-entities 的 encode 进行编码，或使用带自动转义的模板引擎（EJS、Handlebars、React）。
针对文件上传，资料给出校验函数示例：先检查文件大小是否超过限制（示例为 5MB），再通过 file-type 的 fileTypeFromBuffer 依据魔术字节校验真实类型是否在允许列表（如 image/jpeg、image/png、image/webp）中，最后使用 crypto.randomUUID 生成安全文件名，绝不直接使用用户提供的文件名。
针对命令注入，资料对比了 child_process 的 exec 与 execFile：exec 会使用 shell，存在注入风险；execFile 不使用 shell，因此无法注入。
其他框架示例 Laravel/PHP 通过 FormRequest 的 rules() 方法定义校验规则，涵盖 required、email:rfc,dns、max、regex、integer、min、Rule::in 白名单以及 image、mimes、max 等文件规则。Python 使用 Pydantic 的 BaseModel、EmailStr、Field、validator 与 Literal 定义字段约束，并在 FastAPI 中通过类型标注实现自动校验。
验证检查清单 资料提供了一份面向每个 API 端点的检查清单：所有输入字段具备类型验证；字符串字段有最大长度限制；数值字段有最小/最大范围；枚举字段使用白名单而非黑名单；邮箱字段使用正确的邮箱验证；URL 字段验证协议（仅 https）与域名；文件上传检查魔术字节而非仅扩展名；路径参数不能遍历目录；用户输入不得传入 shell 命令；用户输入不得用于动态 import() 或 eval()。
PDPA 2024 后果 资料提到 PDPA 2010（2024 年修订）第 5(1) 与 5(2) 条：最高罚款 RM1,000,000，最高监禁 3 年。资料称路径遍历（Finding #2）允许攻击者下载整个用户数据库，开发者被起诉，因为输入验证是任何合格开发者都应实现的基本安全措施。