移除一层登录，为什么备份 API 也失守了

先给结论

当主应用和备份管理页共用同一端口、同一进程，且认证加在最外层（反向代理或应用入口）时，这层 Basic Auth 保护的是整个路径前缀，不是某一个页面。移除它，所有子路径一起失去保护，包括带写能力的 API。

典型场景：NAS 上 / 是主界面，/backup 是备份管理页，共用 192.0.2.10:20000。为图方便去掉登录弹窗，备份页也对所有人开放了。

为什么会这样

关键在于认证加在哪一层：

简单部署多用前两种：请求进入时校验一次凭据，通过后转发给后端，后端不再判断身份。所以后端并不知道某路径曾被保护。

判断依据：看认证配置写在哪。若是 location / { auth_basic ... } 或统一 app.use(authMiddleware)，就是前缀级；若每个路由各自校验，才是页面级。

备份页 API 为什么更值得注意

备份管理页背后一般有一组接口：config（读写桶、区域、密钥）、test（测试连接）、candidates（列出待备份文件）、upload/remote/delete（上传、查看、删除对象）、history（上传记录）。

这些接口天然带写能力。免登录后，任何能连到该端口的人都可以覆盖存储配置、浏览工作区文件名、上传文件、删除备份对象。密钥通常只回显打码 ID，但配置可被替换成别的桶，足以改变数据流向。

怎么做

方案一：对备份前缀单独加认证

location /backup/ {
    auth_basic "restricted";
    auth_basic_user_file /path/to/app/htpasswd;
    proxy_pass http://127.0.0.1:20000;
}

location / {
    proxy_pass http://127.0.0.1:20000;
}

前缀匹配中更长的规则优先，所以 /backup/ 会先命中。主界面免登录，备份页仍需凭据。

方案二：只允许特定来源访问备份 API

location /backup/api/ {
    allow 192.0.2.0/24;
    allow 100.64.0.0/10;
    deny all;
    proxy_pass http://127.0.0.1:20000;
}

100.64.0.0/10 是常见虚拟组网地址段，以实际网段为准。前提是来源地址可信，不能被 NAT 伪装。

方案三：在应用层加中间件

在备份路由组前挂一道校验，只作用于 /backup/api/*，主应用路由不受影响。

怎么确认生效

# 未带凭据访问备份页，应返回 401
curl -i https://example.com:20000/backup

# 未带凭据调用写接口，应同样被拒
curl -i -X POST https://example.com:20000/backup/api/config

# 带凭据访问，应返回 200
curl -i -u user:pass https://example.com:20000/backup

第一步返回 200 说明认证未覆盖该路径，检查 location 是否写成精确匹配 =，或后端是否绕过代理直连。第一步 401 但第三步也 401，问题在凭据文件。

边界与代价

• 前缀级认证无法区分读写。只想开放浏览、禁止修改，需在应用层按方法或路由拆分权限。
• 来源限制依赖网络拓扑。有反向代理或隧道转发时，来源地址变成转发者，规则失效。
• 免登录本身不是错误。只监听回环地址或仅在可信组网内可达时风险可控。问题在于以为只开放了一个页面，实际开放了一整组接口。
• 改动前确认备份配置和密钥仍在位，避免误清空。

一句话判断规则：认证写在代理或入口中间件里，就默认它保护整个前缀；要精细化，就得下沉到路由层或按来源收口。