上传文件：类型与大小与存储

背景

用户上传是高风险面。校验 Content-Type 不可尽信，还需魔数与白名单。

对个人站与小团队而言，把这类实践写进构建与规则文件，比事后救火便宜。0xKEV 提供浏览器本地工具，方便在不上传的前提下先辨认样本、再决定是否交给自动化。

要点

1. 大小上限。
2. 随机对象名。
3. 权限公网读需签名 URL。
4. 异步扫描。

另外记住：可验证优于「感觉好了」。能量化的用命令与指标；不能量化的至少留下检查清单与复盘记录。

怎么做

1. 收紧上传 API。
2. 测绕过。
3. 分存储桶。
4. 文档。

建议把上述步骤收成团队检查项或 CI 门禁。首次落地选一个痛点场景试点，跑通后再横向复制，避免一次性铺开导致无人维护。

辨认现状 → 写清目标与非目标 → 小步改 → 验证 → 文档化

和本站工具

MIME、字节大小、UUID。

入口：Tools 首页（本地运算、免注册）。隐私说明见 隐私。处理生产样例前请先脱敏。

图片加工管道防解压炸弹。

落地时把「谁负责、何时复查」写清楚，避免清单成为墙上标语。可用日历提醒做季度回顾，删除过时步骤，补充新的失败案例。与本站其他速记交叉阅读，能把部署、安全与成本视角连成一张实践图。

实践上建议建立「最小可重复检查」：每次改动后用同一组命令或同一份清单验证，把结果贴进变更说明。这样后来者不必猜测你当时是否测过。若涉及自动化，先在预发或本地复现，再放到生产路径；失败时保留现场（日志、配置摘要、版本号），方便复盘而不是只留下一句「修好了」。与安全相关的步骤务必默认拒绝、显式允许；与成本相关的步骤务必带预算与度量。0xKEV 速记栏只记录可核实的工程事实，方便检索与内链，不替代你团队自己的 Runbook。

实践上建议建立「最小可重复检查」：每次改动后用同一组命令或同一份清单验证，把结果贴进变更说明。这样后来者不必猜测你当时是否测过。若涉及自动化，先在预发或本地复现，再放到生产路径；失败时保留现场（日志、配置摘要、版本号），方便复盘而不是只留下一句「修好了」。与安全相关的步骤务必默认拒绝、显式允许；与成本相关的步骤务必带预算与度量。0xKEV 速记栏只记录可核实的工程事实，方便检索与内链，不替代你团队自己的 Runbook。

实践上建议建立「最小可重复检查」：每次改动后用同一组命令或同一份清单验证，把结果贴进变更说明。这样后来者不必猜测你当时是否测过。若涉及自动化，先在预发或本地复现，再放到生产路径；失败时保留现场（日志、配置摘要、版本号），方便复盘而不是只留下一句「修好了」。与安全相关的步骤务必默认拒绝、显式允许；与成本相关的步骤务必带预算与度量。0xKEV 速记栏只记录可核实的工程事实，方便检索与内链，不替代你团队自己的 Runbook。

小结

本文只讨论可执行的工程做法。把边界、验证与文档当作一等公民，工具与自动化才能真正省时间，而不是放大事故面。