目前在三种主流的Web做事实现方案中，REST模式做事比较繁芜的SOAP和XML-RPC比拟来讲，更加简洁，越来越多的web做事开始利用REST设计并实现。但其短缺安全特性，《REST API 安全设计指南》便是一个REST API安全设计的指南，权当抛砖引玉，推举网站后台设计及网站架构师们阅读。
1，REST API 简介
REST的全称是REpresentational State Transfer，表示表述性无状态传输，无需session，以是每次要求都得带上身份认证信息。rest是基于http协议的，也是无状态的。只是一种架构办法，以是它的安全特性都需我们自己实现，没有现成的。建议所有的要求都通过https协议发送。RESTful web services 观点的核心便是“资源”。 资源可以用 URI 来表示。客户端利用 HTTP 协议定义的方法来发送要求到这些 URIs，当然可能会导致这些被访问的”资源“状态的改变。HTTP要求对应关系如下：
========== ===================== ========================HTTP 方法 行为 示例========== ===================== ========================GET 获取资源的信息 http://xx.com/api/ordersGET 获取某个特定资源的信息 http://xx.com/api/orders/123POST 创建新资源 http://xx.com/api/ordersPUT 更新资源 http://xx.com/api/orders/123DELETE 删除资源 http://xx.com/api/orders/123========== ====================== =======================
对付要求的数据一样平常用json或者xml形式来表示，推举利用json。
2，身份认证
身份认证包含很多种，有HTTP Basic，HTTP Digest，API KEY，Oauth，JWK等办法，下面大略讲解下：
2.1 HTTP Basic
REST由于是无状态的传输，以是每一次要求都得带上身份认证信息，身份认证的办法，身份认证的办法有很多种，第一种便是http basic，这种办法在客户端哀求大略，在做事端实现也非常大略，只需大略配置apache等web做事器即可实现，以是对付大略的做事来说还是挺方便的。但是这种办法安全性较低，便是大略的将用户名和密码base64编码放到header中。
base64编码前：Basic admin:adminbase64编码后：Basic YWRtaW46YWRtaW4=放到Header中：Authorization: Basic YWRtaW46YWRtaW4=
正是由于是大略的base64编码存储，牢记牢记在这种办法下一定得把稳利用ssl，不然便是裸奔了。 在某些产品中也是基于这种类似办法，只是没有利用apache的basic机制，而是自己写了认证框架，事理还是一样的，在一次要求中base64解码Authorization字段，再和认证信息做校验。很显然这种办法有问题，认证信息相称于明文传输，其余也没有防暴力破解功能。
2.2 API KEY
API Key便是经由用户身份认证之后做事端给客户端分配一个API Key，类似：http://example.com/api?key=dfkaj134,一样平常的处理流程如下： 一个大略的设计示例如下： client端：
server端：
client端向做事端注册，做事端给客户端发送相应的api_key以及security_key，把稳保存不要透露，然后客户端根据api_key,secrity_key,timestrap,rest_uri采取hmacsha256算法得到一个hash值sign，布局途中的url发送给做事端。 做事端收到该要求后，首先验证api_key,是否存在，存在则获取该api_key的security_key，接着验证timestrap是否超过韶光限定，可依据系统成而定，这样就防止了部分重放攻击，途中的rest_api是从url获取的为/rest/v1/interface/eth0,末了打算sign值，完之后和url中的sign值做校验。这样的设计就防止了数据被修改。 通过这种API Key的设计办法加了韶光戳防止了部分重放，加了校验，防止了数据被修改，同时避免了传输用户名和密码，当然了也会有一定的开销。
2.3 Oauth1.0a或者Oauth2
OAuth协议适用于为外部运用授权访问本站资源的情形。个中的加密机制与HTTP Digest身份认证比较，安全性更高。利用和配置都比较繁芜，这里就不涉及了。
2.4 JWT
JWT 是JSON Web Token，用于发送可通过数字署名和认证的东西，它包含一个紧凑的，URL安全的JSON工具，做事端可通过解析该值来验证是否有操作权限，是否过期等安全性检讨。由于其紧凑的特点，可放在url中或者 HTTP Authorization头中，详细的算法就如下图
3 授权
身份认证之后便是授权，根据不同的身份，付与不同的访问权限。比如admin用户，普通用户，auditor用户都是不同的身份。大略的示例：
php$roles = array('ADMIN'=>array('permit'=>array('/^((\/system\/(clouds|device)$/'), // 许可访问哪些URL的正则表达式'deny'=>array('/^(\/system\/audit)$/') // 禁止访问哪些URL的正则表达式),'AUDIT'=>array('permit'=>array('/^(\/system\/audit)$/'),//许可访问的URL正则表达式'deny'=>array('/^((\/system\/(clouds|device).)$/')));
上述是垂直权限的处理，如果碰着了平行权限的问题，如用户A获取用户B的身份信息或者变动其他用户信息，对付这些敏感数据接口都须要加上对用户的判断，这一步一样平常都在详细的逻辑实现中实现。
4 URL过滤
在进入逻辑处理之前，加入对URL的参数过滤，如
/site/{num}/policy
限定num位置为整数等，如果不是参数则直接返回造孽参数，设定一个url清单，不在不在url清单中的要求直接谢绝，这样能防止开拓中的api透露。rest api接口一样平常会用到GET,POST,PUT,DELETE,未实现的方法则直接返回方法不许可，对付POST，PUT方法的数据采取json格式，并且在进入逻辑前验证是否json，不合法返回json格式缺点。
5 主要功能加密传输
第一步推举SSL加密传输，同时对付系统中主要的功能做加密传输，如证书，一些数据，配置的备份功能，同时还得确保具备相应的权限，这一步会在授权中涉及。
6 速率限定
要求速率限定，根据api_key或者用户来判断某段韶光的要求次数，将该数据更新到内存数据库(redis，memcached)，达到最大数即不接管该用户的要求，同时这样还可以利用到内存数据库key在特定时间自动过期的特性。在php中可以利用APC，Alternative PHP Cache (APC) 是一个开放自由的PHP opcode 缓存。它的目标是供应一个自由、 开放，和健全的框架用于缓存和优化PHP的中间代码。在返回时设置X-Rate-Limit-Reset:当前韶光段剩余秒数，APC的示例代码如下：
phpRoute::filter('api.limit', function(){$key = sprintf('api:%s', Auth::user()->api_key);// Create the key if it doesn't existCache::add($key, 0, 60);// Increment by 1$count = Cache::increment($key);// Fail if hourly requests exceededif ($count > Config::get('api.requests_per_hour')){App::abort(403, 'Hourly request limit exceeded');}});
7 缺点处理
对付造孽的，导致系统出错的等要求都进行记录，一些主要的操作，如登录，注册等都通过日志接口输出展示。有一个统一的出错接口，对付400系列和500系列的缺点都有相应的缺点码和干系提示，如401：未授权；403：已经鉴权，但是没有相应权限。如不识别的url:
{\"大众result\"大众:\公众Invalid URL!\公众}
,缺点的要求参数
{\"大众result\"大众:\"大众json format error\"大众}
,不许可的方法：
{\"大众result\"大众:\"大众Method Not Allowed\公众}
，造孽参数等。上面所说的都是单状态码，同时还有多状态码，表示部分成功，部分字符造孽等。示例如下：
HTTP/1.1 207 Multi-StatusContent-Type: application/json; charset=\公众UTF-8\公众Content-Length: XXXX{\"大众OPT_STATUS\公众: 207\"大众DATA\公众: { \公众IP_ADDRESS\"大众: [{ \"大众INTERFACE\"大众: \"大众eth0\公众, \"大众IP_LIST\"大众:[{ \"大众IP\"大众: \"大众192.168.1.1\公众, \公众MASK\"大众: \"大众255.255.0.0\"大众,\"大众MULTI_STATUS\"大众: 200, \"大众MULTI_RESULT\"大众: \"大众created successfully\公众 },{ \"大众IP\公众: \公众192.167.1.1\"大众, \公众MASK\公众: \"大众255.255.0.0\"大众,\公众MULTI_STATUS\"大众: 409, \"大众MULTI_RESULT\公众: \"大众invalid parameter\"大众}]}]},
8 主要ID不透明处理
在系统一些敏感功能上，比如/user/1123 可获取id=1123用户的信息，为了防止字典遍历攻击，可对id进行url62或者uuid处理，这样处理的id是唯一的，并且还是字符安全的。
9 其他把稳事变
(1)要求数据，对付POST,DELETE方法中的数据都采取json格式，当然不是说rest架构不支持xml，由于xml太不好解析，对付大部分的运用json已经足够，近一些的趋势也是json越来越盛行，并且json格式也不会有xml的一些安全问题，如xxe。利用json格式目前能防止扫描器自动扫描。 (2)返回数据统一编码格式，统一返回类型，如Content-Type: application/json; charset=”UTF-8″ (3)在逻辑实现中，json解码之后进行参数验证或者转义操作，第一步json格式验证，第二步详细参数验证基本上能防止大部分的注入问题了。 (4)在传输过程中，采取SSL担保传输安全。 (5)存储安全，主要信息加密存储，如认证信息hash保存。
总之，只管即便利用SSL。
