借助Nuxt等服务端渲染方案保护API及避免SPA接口数据泄露方案问询

方案1：基于现有Nuxt架构改造，完全隐藏内部API #

• 启用Nuxt的服务端路由（Server Routes） 作为统一代理入口：所有客户端的交互请求不再直接调用ASP.NET Core API，而是统一请求Nuxt服务端路由，由Nuxt服务端在内网环境调用你的内部API，内部API直接关闭公网访问权限，仅允许Nuxt服务端IP调用，从根源上避免原始API暴露。
• 服务端路由返回结果可以直接输出渲染后的HTML片段，客户端仅需执行DOM替换操作，全程不会有规整的结构化JSON返回给前端，大幅降低数据爬取的便利性。
• 该方案完全保留SPA的无刷新交互体验，同时满足你最初想靠SSR解决问题的需求，改造成本极低，只需调整前端请求逻辑和新增少量服务端代理代码。

方案2：现有API层增加防护规则，提升爬取门槛 #

如果暂时不想调整整体架构，可以在现有ASP.NET Core API层面叠加多层防护：

• 加动态请求签名校验：所有请求必须携带由前端生成的动态签名，签名与用户ID、时间戳、请求参数强绑定，签名有效期设置为1~2分钟，过期即失效，防止重放攻击。签名生成算法藏在经过高强度混淆的JS代码中，增加逆向破解成本。
• 加细粒度的速率限制：不只是限制单请求返回条数，还要基于用户ID、IP、设备指纹多维度限制请求频率，比如每分钟最多允许请求10次，单用户24小时内最多允许请求200次，按3万条数据的规模，就算每次拿满60条也需要至少几天才能爬完，大幅提升爬取的时间成本。
• 做字段混淆处理：把API返回的JSON字段名全部替换为无意义的短字符，比如原product_name改为a1，price改为x3，仅前端混淆后的JS维护字段映射关系，攻击者即使拿到JSON也无法快速理解数据结构。

方案3：引入BFF（前端专属后端）层做统一收口 #

• 单独搭建一层面向前端的BFF服务，所有前端请求统一接入BFF，原有数据API完全关闭公网访问，仅对BFF层开放。
• BFF层可以做请求聚合、结果裁剪、HTML片段渲染等处理，对外暴露的接口数量可以压缩到最少，同时在BFF层统一实现爬虫拦截规则：比如异常UA拦截、请求行为特征识别（比如没有页面停留时间、请求间隔完全固定的直接封禁）。

方案4：内容层面增加混淆，提升数据清洗成本 #

• 返回的HTML或者JSON中插入随机的无效内容，比如HTML中插入display: none的无效DOM节点，JSON中插入无意义的随机字段，爬虫爬取后需要额外做数据清洗，提升爬取成本。
• 核心敏感字段可以用自定义字体实现混淆：把数字、关键文本的字符编码做自定义映射，攻击者爬取到的原始内容是乱码，只有加载你站点的自定义字体才能正常渲染，对普通用户的使用体验完全没有影响，但对爬取行为的门槛提升非常明显。

以上方案可以根据改造成本自由组合，比如优先选择方案1+速率限制+JS混淆的组合，基本可以过滤掉90%以上的批量爬取行为，符合提升爬取门槛的需求，同时完全保留SPA的交互体验。

内容的提问来源于stack exchange，提问作者Chris Lees