Java生鲜电商平台-生鲜电商如何架构与设计一个安全的API？(APP/小程序)
说明：生鲜电商如何架构与设计一个安全的API？这里的安全的API只是相对而言的概念，并非一定极其安全，任何一个系统都不敢说他们设计的API有多么的安全.
鉴于最近生鲜系统中在对接一些银行机构，结合自己之前对接的一些三方支付机构，下面来谈下这些机构在信息安全网络传输方面都是怎么做的，
通过什么具体手段来保证安全问题，下面主要通过以下几个方面进行分析总结下
1、常见的加密、加签算法
2、银行和支付机构的做法
3、安全的核心问题
4、最佳实践
5、安全需要关注的其它问题
一、常见加密、加签算法
其中算法(国际)列，默认的排序是按照算法的破解难易程度从高到低进行排序，SM2由国家密码管理局于2010年12月17日发布，国密号称安全性优于国际算法，网上找到一篇文章有人验证SM2的加签速度优于RSA，但是验签速度要远远低于RSA，由于未找到权威文章，此处不做结论
二、银行和支付机构的做法
三、安全的核心问题
1、身份认证问题
一般情况下服务端均会向客户端颁发appId、partnerId等类似于标识用户身份的唯一ID，此ID关联用户密钥，一旦服务端异常或者受到工具，可以追溯来源，调整ID状态或者来强制下线用户
2、 信息泄露问题
信息泄露主要是要控制报文在网络传输中不要明文传输，根据对称和非对称加密算法的特点，目前主流的做法是使用混合加密，主要流程是，服务端创建RSA密钥对，将公钥传输给客户端，同时客户端创建AES密钥，使用AES密钥加密明文得到密文，接着使用公钥加密AES密钥，最后将加密后的AES密钥和密文传输到服务端。服务端使用自己的私钥解密加密后的AES密钥得到AES密钥，接着使用AES密钥解密密文得到明文
3、请求被篡改问题
防止请求被篡改主要是要做好加签和验签，以下图例主要说明RSA的验签过程，及RSA的加密流程
4、重放攻击问题
黑客监听到请求后，重复请求攻击服务端，服务端如何识别是非法请求
在请求参数中增加timestamp、randomString参数【此参数是从服务端实时请求的】，服务端在接收到请求后timestamp时间戳和服务端相差1分中之内的才放行，接着判断randomString是否已经存在，如果存在则不响应
四、最佳实践
通过对比以上机构的一些常规做法，以及自己的使用体会，说下我的一些看法
A、尽量提供SDK，完全傻瓜式使用，能极大的缩小接入者的调试成本，以前踩过的坑由于编码或者时区设置问题，导致看似一个简单的问题，花费很大的精力去解决，同样的算法填充方式不一样导致无法解密等等都是走过的血和泪
B、使用JSON方式进行交与，由于相同数据JSON报文要比XML报文小很多，以及JSON报文的可读性强和数据结构展示更加清晰，建议尽量使用JSON、一般银行或者支付机构老系统在沿用XML，基本上已经退出历史舞台了
C、对称加密使用AES、非对称加密使用RSA、摘要算法使用SHA-256、数字签名算法使用SHA256withRSA，因为从理论上来说以上都是目前安全级别最高的算法
D、针对敏感字段的加密能支持一次一密
E、 生产环境一定要使用HTTPS，尽量采用权威CA机构颁发的证书
五、安全需要关注的其它问题
A、越权问题，可能最容易被忽略，此问题应该在系统进行业务层面的校验，如果是网页端含登录态的需要结合登录态来核验用户身份
B、网页端需注意XSS攻击问题
参考链接：
京东支付开放平台：https://payapi.jd.com/
微信支付开放平台：https://pay.weixin.qq.com/wiki/doc/apiv3/wxpay/pages/index.shtml
支付宝开放平台：https://docs.open.alipay.com/
工行开放平台：https://open.icbc.com.cn/icbc/apip/docs_index.html
平安开放平台：http://api.pingan.com/dev/index.do?Fpcl1qGdFgeWKps
4. 代码与架构如何编写呢？
说明：接口安全性问题是一个不可忽略的技术问题，需要在实战中进行提高，可以根据自己的业务自己进行调整，切记生搬硬套.
5. 复盘与总结.
总结：
做互联网应用，无论是生鲜小程序还是APP，目的是为了留住与激活用户，形成用户购买力，提高满意度，最终达成交易的，当然本文只是抛砖引玉，希望本文可以给大家一点思考与建议。
所有的生鲜电商对外的API都是以牺牲性能来提高安全性的，因为加密与解密是很耗费CPU资源的。
QQ:137071249
共同学习QQ群：793305035