提到数据泄露，很多人先想到数据库被攻破，实际上相当一部分事件来自公网上可以直接访问的文件：部署时留下的压缩包、数据库导出的备份、编辑器生成的临时文件、代码仓库的元数据目录。这些文件不需要任何技术手段，只要知道地址就能拿到。
这类文件的共同点是它们本来不该出现在网站目录里，是因为开发、部署或者迁移时的疏忽被留了下来。它们不会被页面链接到，但可以被扫描工具枚举出来。
还有一类是配置文件和日志。它们里面可能包含数据库账号、接口密钥、服务器地址，甚至完整的请求内容。一旦可以被下载，等于把内部结构完整地交出去。
接口返回的字段值得逐一核对。为了方便，很多接口会把整条记录的字段都返回给前端，其中可能有手机号、证件号、内部备注、其他用户的标识。前端不用不代表不该给，只要有权限的人构造一次请求就能看到。
错误提示也是常见的一处。把异常信息原样返回给用户，会带上数据库类型、表名、字段名，甚至部分语句。这些信息对排查问题很方便，对试探的人同样方便。
页面上还可能出现不该显示的细节：注释里的测试账号、隐藏字段中的内部编号、接口地址里带有的凭据参数。这些内容在源码里看得一清二楚。
先做一遍目录层面的检查。把站点根目录完整列出来，看有没有不属于网站的文件；再用外部视角访问几个典型位置，确认它们返回的是拒绝而不是内容。这一步不需要工具，手工就能完成。
再检查页面和接口的返回内容。换一个普通账号，查看接口返回的字段，看有没有超出需要的信息；尝试触发错误，看提示里有没有内部细节。
然后是外部视角的整体检查：站点的历史记录里有没有留下过敏感地址、邮件和文档里有没有出现过凭据、代码仓库是不是公开的。这些位置往往比服务器本身更容易被忽略。
检查时注意不要只看主站。测试环境、预览环境、移动端接口，这些位置的检查常常更松，暴露的风险反而更高。
第一步是把可访问的路径关掉，然后评估这个文件存在了多久、有没有被访问过的记录。访问日志能给出答案，如果日志已经轮转掉，那就要假设它已经被看到过。
涉及凭据的，立即更换相关密码和密钥，并检查有没有异常的使用记录。更换的范围要覆盖所有引用到这些凭据的地方，漏掉一处就留了缺口。
涉及个人信息的，要按照内部流程评估影响并安排后续处理。这一步不能只靠技术判断，需要业务和管理岗位一起确认。
处理完之后，把这类检查纳入上线前的固定环节。大部分泄露是可以提前避免的，代价只是发布之前多花十几分钟。
文件不公开只是第一步，还要确认访问路径本身是可控的。上传目录不应该允许执行脚本，备份目录不应该能被直接访问，这些都在服务器配置里设置，而不是靠文件名不容易被猜到。
目录列表功能要关闭。有些服务器在找不到默认页面时会把目录内容列出来，等于把文件清单直接展示给来访者，包括那些本来不该被下载的文件。
访问日志值得翻一翻，看看有没有针对常见敏感路径的请求。这类请求往往来自扫描工具，说明已经有人在尝试枚举，及时处理能避免后续更大的问题。
一次检查能解决当下已知的问题，长期有效还是靠固定动作。可以把这类检查放进发布流程和季度巡检，形成习惯之后，成本会明显下降。
整理一份站点的文件清单，写清楚每个目录的用途，日后新增内容时可以对照，避免又出现不该公开的文件。
图片和文档在发布前常会带上拍摄位置、编辑软件和作者信息，这类内容不一定需要公开。批量处理时把这些信息去掉，再上传到站点上，成本不高，能省去后来的很多解释。
发布用的目录和内部存放的目录建议分开，避免把整理过程中的中间文件也一起放了上去。
售后客服
企业微信
