双方约定好密钥，在传输前对原报文进行一个加密，传输至服务端或客户端再进行解密，因为此类方式不同于HTTPS方式，所以还是有以下风险
• 密钥不是一次一密，而且是内嵌在代码中，都有可能被获取。
• 如果是基于浏览器的工程，那么这个密钥是内嵌在js中的，而js是可以访问的，那么就有可能被获取。
• 如果是app工程中，也有可能被反编译获取。
不验证通信方的身份，因此有可能遭遇伪装HTTP协议的请求与响应不会对通信方进行身份的确认，因此这种无法确认通信方，总结有以下几类问题：
• 无法确定请求目标的Web服务器是否，真正要访问的服务器。
• 无法确定客户端是否是真实要响应的客户端。
• 无法确定正在通信的双方是否具备访问权限，比如：提供的WEB服务只想开发给指定的客户端访问。
• 无法判定请求来自何方，出自谁手。
• 即使是无意义的请求，也会照单全收。如海量的Dos攻击。
如何防止使用SSL才可以防止此类问题，SSL不仅提供加密功能，还提供证书，通过证书可以确定通信的方是意料之中的，这里肯定有人会问那证书如何保证可信呢？
证书是有公认值得信赖的CA机构颁发的，其他机构是没有颁发证书权限的。CA机构是可信赖的，那么颁发的证书也是可信赖的。
客户端验证服务端是否是可信的服务端，即单向认证。
客户端与服务端相互认证，即双向认证。
无法证明报文的完整性，有可能会被篡改所谓完整性是指信息的准确度，无法证明完整性，那么也就无法判定信息是否准确。
由于HTTP协议无法证明通信的完整性，那么请求或者响应过程中报文就有可能被篡改，而服务端或者客户端是无法感知的。
比如从网上下载的内容，是无法确认下载后的内容是否跟服务器上的内容一致。
像这样在请求/响应途中，遭攻击者拦截并篡改内容攻击，称为中间人攻击。
