H5应用加固前如何确定接口签名方式
很多H5应用在接入加固前，接口已经有自己的签名校验机制。作为开发者或安全人员，应该从哪些表现去识别当前接口使用的是哪类签名方式，比如参数拼接、时间戳、随机数、Token参与签名，还是加密后整体传输？
通过请求特征、前端代码和服务端返回表现综合判断
可以从三方面入手判断：一是抓包观察接口请求参数，重点看是否存在固定的签名字段，如 sign、signature、token、nonce、timestamp 等；二是查看H5前端代码，搜索签名生成逻辑，确认参与签名的字段、拼接顺序、哈希算法或加密算法；三是通过修改单个参数做对比测试，观察服务端是否返回签名错误、参数非法或校验失败。结合这些信息，通常就能判断出接口是采用MD5、HMAC、AES、RSA，还是混合型签名方案。
在准备对H5应用做加固时，如果接口签名规则没有文档，或者前后端代码里很难看清楚签名逻辑，这种情况下会不会影响加固方案的选择？应该优先确认哪些内容，避免加固后接口异常？
会影响，加固前应确认签名依赖项和校验位置
会有明显影响，因为加固可能改变参数顺序、代码结构或运行环境，进而影响签名结果。建议优先确认三项内容：签名由前端生成还是由网关或服务端生成、参与签名的字段是否包含动态数据、签名逻辑是否依赖浏览器环境中的特定对象或时序。只有把这些依赖点确认清楚，才能选择不破坏签名链路的加固方式，例如保持原始运行逻辑、对关键函数做保护，或者把敏感逻辑迁移到更稳定的安全层。
做H5接口分析时，经常只能看到网络请求和响应。仅靠抓包信息，能不能初步判断签名是简单参数拼接后再哈希，还是经过了加密算法处理？如果能判断，通常有哪些可观察的特征？
可以通过字段形态、稳定性和可逆性特征进行初判
可以做初步判断。若请求中出现可读参数与一个短签名字段，且参数变化时签名规律明显，通常更像是拼接后做哈希；若请求体内容整体不可读、长度较固定，且每次请求都呈现高随机性，往往意味着做了加密传输。还可以对比同一接口多次请求：如果只改一个参数，签名同步变化但结构不变，多半是明文拼接参与计算；如果整包内容都变化且难以直接读出业务字段，可能是整体加密。
有些H5接口在本地调试时正常，但一旦更换环境、修改WebView或进行加固，就出现签名不通过。对于这种情况，是否需要提前确认签名逻辑是否依赖浏览器指纹、UA、Cookie、LocalStorage或JS运行上下文？
需要，环境依赖是签名失效的常见原因
需要提前确认，因为很多H5签名并不只依赖参数本身，还会结合浏览器环境信息，例如User-Agent、Cookie、设备标识、时区、页面来源或本地存储中的临时值。加固后如果改变了脚本执行顺序、缓存策略或运行容器，这些依赖项就可能失效。建议在加固前梳理签名输入来源，并通过多环境测试验证签名是否稳定，这样可以降低加固后接口校验失败的风险。