React前端每秒向Spring Boot后端发GET请求模拟实时应用是否安全

首先说核心判断：你这套方案的核心安全逻辑是站得住的，100人规模下4核服务器也完全能扛住性能压力，没有架构层面的致命问题。 #

安全性层面分析 #

你把余额校验、交易落地、余额更新这类核心逻辑全放在Spring后端实现，前端不做任何业务状态的可信计算，这个思路本身是对的——前端代码对用户完全透明，本来就不能作为安全边界，就算你做了完整的前端MVC模型层，恶意用户照样可以改前端逻辑绕过去，只要后端校验没缺位，就不会出现余额被篡改、无校验超额转账这类低级安全问题。

但你现在的实现有几个必须补全的安全点，和前端有没有模型层无关，纯后端接口层面的要求：

• 所有拉取交易记录、余额数据的GET接口必须做严格的权限校验：要和当前登录用户的身份强绑定，绝对不能出现靠传参里的用户ID就能拉取任意用户数据的问题；企业场景还要做数据范围隔离，普通员工只能看自己发起的交易，管理员只能看所属企业的全量数据，绝对不能跨租户泄露数据。
• 拉取金融敏感数据的接口必须配置Cache-Control: no-store响应头，禁止浏览器、中间代理缓存交易记录、余额这类敏感信息，避免公共终端、代理节点泄露数据。
• 轮询接口要加基础的频率限制，单用户每秒最多允许1次请求，防止恶意用户篡改前端代码把请求频率拉高刷垮服务，也能挡住未登录的恶意扫描请求。
• 电汇这类写操作接口必须做幂等校验，要靠请求唯一标识判断重复请求，避免用户重复点击、网络重试导致同一笔交易重复扣款，这是金融类系统的必做项。

性能层面分析 #

你担心的轮询压力在100用户规模下根本不是问题：

• 满打满算100个用户同时在线，每秒1次轮询，总QPS才100，4核服务器跑Spring服务+常规数据库查询，这个负载连服务器30%的性能都用不到，完全没必要为了所谓的"实时性"花额外时间搭WebSocket、长连接方案，轮询是开发成本最低、出问题概率最小的选择。
• 你现在增删改操作后直接拉全量数据刷新页面的思路也完全可行，100人规模的内部企业应用，单用户的交易数据量不会大到造成明显的页面卡顿；真要是遇到数据量太大加载慢的问题，给接口加个分页、默认只拉最近3个月的交易记录就能解决，完全没必要为了"架构规范"回头补前端模型层，省下来的时间多补点后端参数校验、异常场景处理的逻辑性价比高得多。

唯一可以优化的小细节：如果后续发现轮询请求里大部分时候数据都没变化，可以给接口加个基于数据更新时间的判断，前端请求带上上次拿到数据的最新时间戳，后端比对如果数据没更新就直接返回304不传输全量数据，能省点带宽，这个改动量很小，不做也完全不影响使用。

内容的提问来源于stack exchange，提问作者Youssef Idraiss