开发涉及的安全规范整理

#1024程序员节|征文#

文章目录

前言

  这篇文章我们来整理下写代码和方案设计中的安全规范问题，内容偏服务端，即使是入门的新人，如果你对安全有所了解会让成熟规范的团队对你高看一眼。安全经常是在风平浪静时被大家所忽视，出事了再弥补，实际上安全工作首先要做的是防患于未然而不是亡羊补牢，成熟的公司和团队会给开发制定严格的安全编码规范，大家自己团队里最重视的安全措施有哪些？可以评论分享下，本文尽可能给大家罗列一些基本的安全措施。

安全场景与措施

API调用方式

  不能使用公网IP加端口的http方式请求，要用https协议加上API域名的方式去访问后端的API，https协议作为传输通道更安全，实际生产中大家都是这样做的。

鉴权

  不管是提供给客户端的外部接口还是服务间调用的内部接口，都不能免鉴权给用户访问，除非用户注册这种特殊功能接口或者你们的应用是不带账号登录的，否则，用户登录后能执行的操作涉及到访问后端API时，后端必须接收登录token并解析鉴权，token的生成方式常用的是JWT。

参数校验

  参数校验是一个很基本的安全规范措施，因为参数传入的攻击类型很多，比如SQL注入、JS脚本注入、日志注入（后文特别提到）等，要针对性的拦截掉可能的攻击参数，提示参数无效。

日志打印

  要注意，敏感信息不能在服务器日志中打印，服务器日志被认为是可窃取的，对于用户联系账号、密码、身份证号等敏感信息在日志中不能打印，或者只能脱敏打印（就像快递联系方式中间都是*****一样）。另外就是参数校验的时候要考虑日志注入的校验，因为别人有可能传参的时候传了一个服务器命令过来，如果这时候日志打印了的话，很可能造成外部命令的执行。

数据保存加密

  对于敏感的用户信息数据，存数据库的时候要加密保存，比如账号和密码，账号一般采用可逆的加密算法，密码一般采用不可逆的（不需要能解密），比较密码是否正确只需要比较加密值是否一样即可。特别要提一点，就算是redis这种缓存数据库，用户信息也不能明文地作为key-value去保存。

总结

  安全规范的要求其实远不止本文所说的这些，即使是上面这些安全措施，比如涉及到某些加密方式涉及到加密迭代次数设置的，都会要求要1000次或者100000次以上这种细节的要求。安全无小事，希望各位开发们注意安全。