客户端请求发送JSON数据的常见场景
在日常使用各类App或网页时，比如登录账户、提交订单、修改密码，背后其实都是客户端在悄悄发送JSON格式的数据给服务器。比如你在某购物App点击“提交订单”后，手机会把商品ID、数量、收货地址这些信息打包成一段JSON，通过网络请求传出去。
{"product_id": 1024, "count": 2, "address": "北京市朝阳区某某街道"}这种结构清晰、体积小的数据格式成了现代应用通信的标配。
明文传输的风险你可能没意识到
很多人以为只要功能通了就没问题，但直接发送原始JSON就像把便条贴在快递包裹外面。公共Wi-Fi环境下，攻击者用抓包工具一扫，你的手机号、身份证号甚至支付信息都可能被截获。
曾有用户反馈，在咖啡厅连免费Wi-Fi点了个“忘记密码”，结果半小时内账号被盗。排查发现，重置请求中的手机号和设备标识是明文JSON，被中间人轻松捕获并复用。
加一层“信封”更安全
给JSON数据套上HTTPS是最基本操作。但这还不够，敏感字段建议提前加密。比如密码字段不传明文，而是客户端先用AES加密，服务器再解密验证。
{"username": "zhangsan", "password_enc": "a1b2c3d4e5f6..."}同时加上时间戳和签名，防止请求被截获后重复提交。就像寄重要文件，不仅要密封，还得盖上“限时签收”章。
别让错误提示泄露细节
有些应用在请求出错时返回详细JSON说明，比如"error": "invalid user_id format"。这等于告诉攻击者接口校验逻辑，反而方便他们构造恶意数据。
更稳妥的做法是统一返回模糊提示，日志留在服务器端查。普通用户看到“操作失败”就够了，没必要知道是参数错了还是网络抖动。
前端代码里藏着的隐患
开发调试时，有人习惯在JS里写死测试用的JSON模板，上线忘了删。这类静态数据一旦被反编译提取，就等于把钥匙留在门垫下面。
还有些第三方库默认开启调试模式，会自动打印所有发出的请求内容。记得打包前关掉相关配置，避免无意中“自曝家门”。
模拟请求也能骗过系统？
现在不少攻击是用脚本模拟客户端行为，批量发伪造JSON刷接口。防御的关键是加入设备指纹和行为验证。比如每次请求带上设备唯一ID和操作时间序列，异常高频请求直接拦截。
就像银行对频繁转账的账户临时冻结一样，系统得有自己的“风控雷达”。
做好这些细节，不只是为了防黑客，更是让用户安心。毕竟谁都不希望自己的点餐记录变成别人手里的隐私地图。