API 如何检测安全配置是否有错误？

个人经验应该有这么几个方面：

鉴权的基础验证

鉴权的基础验证检验调用方是否提供了有效的，符合定义的 API 密钥。

我们在连接世界的API门槛是怎么越来越高的？（一）中讲了 API 鉴权的发展过程。这些发展趋势其实就对应了 API 鉴权过程中发生过的多种问题。

所以，基础测试要测试的内容包括（下面问题也有可能是设计问题，基本是关于 API 鉴权基础设计的所有问题了）：

1. 不提供用户名、不提供密钥是否会验证通过。

2. 验证值是否和内容绑定，改变提交内容同时不改变验证值，是否会验证通过。

3. 部分内容为空是否会影响验证，在文章中，我们提到 API Key 最后发展的趋势是在所有数值中加入一个文本的"+",就是为了区分哪个数值为空，所以需要测试不同值为空时的问题。

4. 如果参数有时间值，需要测试非当前时间的返回，API 加入时间通常是为了限制请求必须在合理的时间内执行，可以保留一个请求，并在设计的安全时间之后再重新发送，看是否还能正常调用通过。

5. 验证数值的长度和大小写是否有问题，尤其是各类以 MD5 为验证值生成方式的鉴权方式中，验证值是否需要全小写或者全大写才能比对通过等问题。

上述测试，1，2，4 正常情况下应该返回错误报警,3，5 看具体的配置值。

Oauth2 的话，要补充测试刷新机制和重新请求机制是否正确，是否只能在规定有效的请求时间内进行刷新和重新请求，同时并发性也是需要测试的点，因为调用方可能会有多个客户端同时进行密钥的刷新和重新请求，对相关并发请求是否按要求合理返回也是需要进行测试的点。

鉴权的高级验证

鉴权的高级验证主要验证包的重复发送等复杂场景，。

重复发送场景

API 设计中，经常会有不能重复发送的接口，例如短信发送等场景，但是仍然需要避免客户端因错误网络调用或者其他问题导致的程序性重复调用，这些都是 API 功能设计中要避免的异常请求问题。这类功能的避免，程序上通常是使用附带请求时间参数，或者进行短时缓存，并在缓存期间进行排重以避免相关问题等方式进行的，所以在测试中也需要针对相对应设计的完整性。

回调正确性

API 设计中，对于时间上耗费较长的请求，我们通常会设计回调模式，回调模式会向请求方提供一个参数，通过该参数，客户端可以提供一个 URL，让服务器在完成数据获取后，通过主动调取该接口的形式，将数据重新传回请求方。

围绕回调，我们也有大量需要测试的工作：

1. HTTP/HTTPS 测试，回调是否执行 HTTP/HTTPS 等多种类型地址的回调。

2. 调用方式测试，回调是否使用了正确的调用方式进行回调，GET/POST/PUT/PATCH/DELETE 等。

3. 调用超时处理，服务器是否设置了合理的回调超时时间，以避免回调过程长时间挂起。

基础协议的符合度测试

由于 API 接口通常是基于 HTTP 接口对外提供服务的，因此，也会有大量需要符合 HTTP 规范的测试需要完整。

1. HTTP GET 参数长度限制问题，很多初学者在设计 API 接口时，会选择 GET 作为开放方式，却忽略了 GET 由于参数都只能编码到 URL 中，经常会遇到的参数超长的问题。这时，参数会被切断，造成请求错误。同时，请求如何是由浏览器发起的，我们还需要注意，这个长度限制不同浏览器是不同的，需要根据浏览器设置测试案例。

1. HTTP GET 中的 URL 转码问题，GET 作为 API 调用，还需要测试入参是否会因为转码造成问题，例如带+号的入参，在编入参数时，应该进行 URL ENCODE，转码为 %2B，请求的客户端和服务端都需要测试特殊输入情况下是否正确执行过程。相关列表较长，搜索“url 转码表”可获得内容，这里从网上粘贴一个：URL编码原理及对照表有个特别的问题要注意，有些接口还会要求参数进行 BASE64 编码，要注意 BASE64 输出结果中有+号，=号等不符合 URL 规范的字符，要测试 BASE64 结果和 url encode 的配置情况。

1. HTTP GET 还有个大的问题是容易泄露，因为 GET 所有参数都编码在 url 中，而且 GET 请求是直接可以在浏览器打开的，因此 GET 类接口要配合时间限制参数等验证请求是否可以通过粘贴复制就无限制重新发送。

2. Content-Type 问题，Content-Type 是我们在开发 API 和使用 API 中都会频繁遇到问题的地方，一个正确的 API 应做到正确的定义 Content-Type, JSON 数据使用 applicaton/json，XML 数据使用 application/xml 正确的响应 Accept，是否根据客户输入的 Accept 返回正确的内容，当然一般 API 都无法提供多种数据响应模式，这时，至少应该做到第 1 点。注意 application/x-www-form-urlencoded 和 multipart/form-data 的不同，当使用 form 进行数据提交的时候，注意这两个方式的不同，一个是把参数编码到 url 里面，一个是放到 body 中。API 的 Content-Type 通常设置为 application/json 等值，经常性会忽略掉 Content-Type 还需要设置编码，编码错误会造成非英文内容解码错误，这也是需要测试的地方。

1. HTTP 设置的请求超时，响应超时等问题，HTTP 请求超时包括 TCP 超时和 HTTP 超时两个层面的超时可能性，TCP 超时就是连接超时，HTTP 超时是指虽然连接没有出现问题，但是 HTTP 请求没有正常发送的情况，这些都是需要进行测试的的地方。

调用性验证

调用性验证主要验证数据本身的正确性。这种情况主要发生在 JSON 请求上，因为 JSON 支持字符串和数值类型，同时，数值类型又将整形和浮点数统一采用同一类型进行的处理（字符串和数值区别就是请求内容是否用""或者''包围，包围的都认为是字符串），因此，有几个问题要测试：

1. 输入类型是否正确

2. 不完整请求时的处理情况（不完整引号，不完整对象）

3. 浮点数处理（精度问题）

攻击类验证

API，特别是收费 API，在防止泄露、攻击等安全问题上一般都有相关的设计和要求。这时要进行针对的测试

1. DDOS 攻击，DDOS 攻击就是大量并发请求，造成服务器死机的攻击，这类攻击有对应的工具进行防护，可根据 API 的开放程度进行测试。

2. 泄露攻击，请求是否容易被中间人通过抓包或者其他方式进行截取并重复发送并获得数据或调取功能，比如是否可以通过反复刷新 GET 链接获取数据，请求网址是否开放了 HTTP，从而可以抓包等问题，抓包获取明文是否可以直接重复提交等都是需要测试的点。

3. IP 白名单测试，如果 API 有白名单功能，应测试 IP 白名单的有效性。

文档一致性

其实我觉得 API 还有一大块问题是需要测试的，就是文档本身的测试，文档是否准确的描述了接口，其实也是很重要的，需要测试的问题。因为文档几乎就是一个调用方了解一个接口的唯一渠道，文档的准确度决定了一个接口的专业程度。

当然百家饭倡导的以 OpenAPI 进行接口定义，并且分发标准 API 描述文档是最好的了，我们看到像中国移动等，也在他们的 IT 开放平台中的部分接口上向外提供了 Swagger 文档（OpenAPI 的俗名）的下载，希望越来越多的工作被标准化，简化我们对接 API 的复杂度。