Question

Let’s explore some of the vulnerabilities that affect APIs and the steps you can take to discover them. API vulnerabilities are similar to the ones that affect non-API web applications, so make sure you have a good understanding of the bugs we’ve discussed up to this point. That said, when testing APIs, you should focus your testing on the vulnerabilities listed in this section, because they are prevalent in API implementations.

让我们探索一些影响 API 的漏洞以及你可以采取的措施来发现它们。API 漏洞与影响非 API Web 应用程序的漏洞类似，因此请确保你对我们到目前为止讨论的错误有良好的理解。话虽如此，在测试 API 时，您应该专注于本部分列出的漏洞，因为它们在 API 实现中很普遍。

Before we dive in, there are many open source API development and testing tools that you can use to make the API testing process more efficient. Postman ( https://www.postman.com/ ) is a handy tool that will help you test APIs. You can use Postman to craft complex API requests from scratch and manage the large number of test requests that you will be sending. GraphQL Playground ( https://github.com/graphql/graphql-playground/ ) is an IDE for crafting GraphQL queries that has autocompletion and error highlighting.

在我们深入研究之前，有许多开源 API 开发和测试工具可用于使 API 测试过程更有效。Postman (https://www.postman.com/) 是一个方便的工具，可帮助您测试 API。您可以使用 Postman 从头开始构建复杂的 API 请求，并管理将要发送的大量测试请求。GraphQL Playground (https://github.com/graphql/graphql-playground/) 是一个可用于编写 GraphQL 查询的 IDE，具有自动完成和错误突出显示。

ZAP has a GraphQL add-on ( https://www.zaproxy.org/blog/2020-08-28-introducing-the-graphql-add-on-for-zap/ ) that automates GraphQL introspection and test query generation. Clairvoyance ( https://github.com/nikitastupin/clairvoyance/ ) helps you gain insight into a GraphQL API’s structure when introspection is disabled.

ZAP 拥有一个 GraphQL 附加组件（https://www.zaproxy.org/blog/2020-08-28-introducing-the-graphql-add-on-for-zap/），用于自动化 GraphQL 的 introspection 和测试查询生成。当 introspection 被禁用时，Clairvoyance（https://github.com/nikitastupin/clairvoyance/）可帮助您了解 GraphQL API 的结构。

Performing Recon

First, hunting for API vulnerabilities is very much like hunting for vulnerabilities in regular web applications in that it requires recon. The most difficult aspect of API testing is knowing what the application expects and then tailoring payloads to manipulate its functionality.

首先，寻找 API 漏洞与寻找常规 Web 应用程序中的漏洞非常相似，需要进行侦察。API 测试最困难的方面在于了解应用程序的预期，然后定制有效负载以操作其功能。

If you’re hacking a GraphQL API, you might start by sending introspection queries to figure out the API’s structure. If you are testing a SOAP API, start by looking for the WSDL file. If you’re attacking a REST or SOAP API, or if introspection is disabled on the GraphQL API you’re attacking, start by enumerating the API. API enumeration refers to the process of identifying as many of the API’s endpoints as you can so you can test as many endpoints as possible.

如果你正在攻击一个 GraphQL API，你可能会从发送自我检视查询开始，以了解 API 的结构。如果你正在测试一个 SOAP API，请从寻找 WSDL 文件开始。如果你攻击的是一个 REST 或 SOAP API，或者 GraphQL API 上的内省被禁用了，那么请从枚举 API 开始。API 枚举是指识别尽可能多的 API 端点的过程，以便你可以测试尽可能多的端点。

To enumerate the API, start by reading the API’s public documentation if it has one. Companies with public APIs often publish detailed documentation about the API’s endpoints and their parameters. You should be able to find public API documentations by searching the internet for company_name API or company_name developer docs . This documentation provides a good start for enumerating API endpoints, but don’t be fooled into thinking that the official documentation contains all the endpoints you can test! APIs often have public and private endpoints, and only the public ones will be found in these developer guides.

要列举 API，首先读取 API 的公共文档（如果有的话）。有公共 API 的公司通常会发布 API 端点和参数的详细文档。通过在互联网上搜索 company_name API 或 company_name 开发者文档，您应该能够找到公共 API 文档。这份文档为列举 API 端点提供了良好的起点，但不要被认为官方文档包含了您可以测试的所有端点所欺骗！API 通常具有公共和私有端点，而这些开发者指南中只有公共端点。

Try using Swagger ( https://swagger.io/ ), a toolkit developers use for developing APIs. Swagger includes a tool for generating and maintaining API documentation that developers often use to document APIs internally. Sometimes companies don’t publicly publish their API documentation but forget to lock down internal documentation hosted on Swagger. In this case, you can find the documentation by searching the internet for company_name inurl:swagger . This documentation often includes all API endpoints, their input parameters, and sample responses.

尝试使用 Swagger（https://swagger.io/）——这是一款开发人员用于开发 API 的工具包。Swagger 包含一个用于生成和维护 API 文档的工具，开发人员通常使用它来在内部记录 API。有时，公司不会公开发布其 API 文档，但会忘记锁定托管在 Swagger 上的内部文档。在这种情况下，您可以通过在互联网上搜索 company_name inurl：swagger 来查找文档。该文档通常包括所有 API 终结点、它们的输入参数和示例响应。

The next thing you can do is go through all the application workflows to capture API calls. You can do this by browsing the company’s applications with an intercepting proxy recording HTTP traffic in the background. You might find API calls used in the application’s workflow that aren’t in public documentation.

下一步您可以浏览公司的应用程序并使用拦截代理记录后台 HTTP 流量来捕捉 API 调用。您可能会发现在应用程序工作流中使用的 API 调用并没有在公共文档中列出。

Using the endpoints you’ve found, you can try to deduce other endpoints. For instance, REST APIs often have a predictable structure, so you can deduce new endpoints by studying existing ones. If both /posts/POST_ID/read and / posts/POST_ID/delete exist, is there an endpoint called /posts/POST_ID/edit ? Similarly, if you find blog posts located at /posts/1234 and /posts/1236 , does / posts/1235 also exist?

通过已发现的端点，你可以尝试推断其他的端点。例如，REST API 经常有可预测的结构，所以你可以通过研究已有的端点推断新的端点。如果 /posts/POST_ID/read 和 /posts/POST_ID/delete 都存在，那么是否存在一个 /posts/POST_ID/edit 的端点呢？同样地，如果你发现博客文章位于 /posts/1234 和 /posts/1236，那么 /posts/1235 是否也存在？

Next, search for other API endpoints by using recon techniques from Chapter 5 , such as studying JavaScript source code or the company’s public GitHub repositories. You can also try to generate error messages in hopes that the API leaks information about itself. For example, try to provide unexpected data types or malformed JSON code to the API endpoints. Fuzzing techniques can also help you find additional API endpoints by using a wordlist. Many online wordlists are tailored for fuzzing API endpoints; one example wordlist is at https://gist.github.com/yassineaboukir/8e12adefbd505ef704674ad6ad48743d/ . We will talk more about how to fuzz an endpoint in Chapter 25 .

接下来，通过使用第 5 章的侦察技术，例如研究 JavaScript 源代码或公司的公共 GitHub 存储库，搜索其他 API 端点。您还可以尝试生成错误消息，以期望 API 泄露有关自身的信息。例如，尝试向 API 端点提供意外的数据类型或格式错误的 JSON 代码。模糊技术也可以通过使用单词表来帮助您找到其他 API 端点。许多在线单词表都是针对模糊 API 端点的;一个例子单词表网址为 https://gist.github.com/yassineaboukir/8e12adefbd505ef704674ad6ad48743d/。我们将在第 25 章中更详细地讨论如何模糊端点。

Also note that APIs are often updated. While the application might not actively use older versions of the API, these versions might still elicit a response from the server. For every endpoint you find in a later version of the API, you should test whether an older version of the endpoint works. For example, if the /api/ v2 /user_emails/52603991338963203244 endpoint exists, does this one: / api/ v1 /user_emails/52603991338963203244 ? Older versions of an API often contain vulnerabilities that have been fixed in newer versions, so make sure to include finding older API endpoints in your recon strategy.

请注意，API 通常会进行更新。虽然应用程序可能不会主动使用 API 的旧版本，但这些版本仍然可能引发服务器的响应。对于您在 API 的较新版本中找到的每个端点，都应该测试旧版本端点是否可行。例如，如果存在/api/v2/user_emails/52603991338963203244 端点，那么这个端点/api/v1/user_emails/52603991338963203244 是否存在？API 的旧版本通常包含修复在较新版本中修复的漏洞，因此请确保包括在您的 recon 策略中发现旧的 API 端点。

Finally, take the time to understand each API endpoint’s functionality, parameters, and query structure. The more you can learn about how an API works, the more you’ll understand how to attack it. Identify all the possible user data input locations for future testing. Look out for any authentication mechanisms, including these:

最后，请花时间了解每个 API 端点的功能、参数和查询结构。您了解 API 如何运作，就越能理解如何攻击它。识别所有可能的用户数据输入位置以备未来测试。留意任何身份验证机制，包括以下内容：

• What access tokens are needed?
• Which endpoints require tokens and which do not?
• How are access tokens generated?
• Can users use the API to generate a valid token without logging in?
• Do access tokens expire when updating or resetting passwords?

Throughout your recon process, make sure to take lots of notes. Document the endpoints you find and their parameters.

在整个侦察过程中，一定要记下很多笔记。记录你找到的端点及其参数。

Testing for Broken Access Control and Info Leaks

After recon, I like to start by testing for access-control issues and info leaks. Most APIs use access tokens to determine the rights of the client; they issue access tokens to each API client, and clients use these to perform actions or retrieve data. If these API tokens aren’t properly issued and validated, attackers might bypass authentication and access data illegally.

在重新调查之后，我喜欢从测试访问控制问题和信息泄露开始。大多数 API 使用访问令牌来确定客户端的权限；它们向每个 API 客户端发放访问令牌，客户端使用这些令牌执行操作或检索数据。如果这些 API 令牌没有正确发放和验证，攻击者可能会绕过身份验证并非法访问数据。

For example, sometimes API tokens aren’t validated after the server receives them. Other times, API tokens are not randomly generated and can be predicted. Finally, some API tokens aren’t invalidated regularly, so attackers who’ve stolen tokens maintain access to the system indefinitely.

例如，有时服务器收到 API 令牌后并不会验证它们。有时，API 令牌不是随机生成的，可以被预测出来。最后，有些 API 令牌不会定期失效，因此窃取令牌的攻击者可以无限期地访问该系统。

Another issue is broken resource or function-level access control. Sometimes API endpoints don’t have the same access-control mechanisms as the main application. For example, say a user with a valid API key can retrieve data about themselves. Can they also read data about other users? Or can they perform actions on another’s behalf through the API? Finally, can a regular user without admin privileges read data from endpoints restricted to admins? Separately from REST or SOAP APIs, the GraphQL API of an application may have its own authorization mechanisms and configuration. This means that you can test for access-control issues on GraphQL endpoints even though the web or REST API of an application is secure. These issues are similar to the IDOR vulnerabilities discussed in Chapter 10 .

另一个问题是资源或功能级别的访问控制被破坏。有时 API 端点没有与主要应用程序相同的访问控制机制。例如，如果一个拥有有效 API 密钥的用户可以检索有关自己的数据，那么他们是否也可以读取其他用户的数据？或者他们是否可以通过 API 代表其他人执行操作？最后，普通用户是否可以在没有管理员权限的情况下读取仅限管理员的端点的数据？除 REST 或 SOAP API 之外，应用程序的 GraphQL API 可能具有其自己的授权机制和配置。这意味着即使应用程序的 Web 或 REST API 是安全的，您也可以测试 GraphQL 端点的访问控制问题。这些问题类似于第 10 章讨论的 IDOR 漏洞。

Other times still, an API offers multiple ways to perform the same action, and access control isn’t implemented across all of them. For example, let’s say that a REST API has two ways of deleting a blog post: sending a POST request to /posts/POST_ID/delete and sending a DELETE request to /posts/POST_ID . You should ask yourself: are the two endpoints subject to the same access controls?

有时候，API 提供了多种执行相同操作的方式，而访问控制并没有在所有方式上实现。例如，假设一个 REST API 有两种删除博客文章的方法：向 /posts/POST_ID/delete 发送 POST 请求和向 /posts/POST_ID 发送 DELETE 请求。你应该问问自己：这两个端点是否受到相同的访问控制？

Another common API vulnerability is information leaks. API endpoints often return more information than they should, or than is needed to render the web page. For example, I once found an API endpoint that populated a user’s profile page. When I visited someone else’s profile page, an API call was used to return the profile owner’s information. At first glance, the profile page didn’t leak any sensitive information, but the API response used to fetch the user’s data actually returned the profile owner’s private API token as well! After an attacker steals the victim’s API token by visiting their profile page, they could impersonate the victim by using this access token.

另一个常见的 API 漏洞是信息泄露。API 端点通常返回比所需或应返回的信息多。举例来说，我曾经发现了一个 API 端点，用于填充用户的个人资料页面。当我访问其他人的个人资料页面时，API 调用则用于返回资料所有者的信息。初看起来，个人资料页面并未泄漏任何敏感信息，但用于获取用户数据的 API 响应实际上还返回了资料所有者的私人 API 令牌！攻击者在访问受害者的个人资料页面后，可以窃取其 API 令牌，并利用该访问令牌冒充受害者。

Make a list of the endpoints that should be restricted by some form of access control. For each of these endpoints, create two user accounts with different levels of privilege: one that should have access to the functionality and one that shouldn’t. Test whether you can access the restricted functionality with the lower-privileged account.

制定一个应该受到某种访问控制限制的端点列表。对于这些端点中的每一个，创建两个不同权限级别的用户账户：一个应该有权访问功能，另一个则没有权限。测试您是否可以使用低权限账户访问受限功能。

If your lower-privileged user can’t access the restricted functionality, try removing access tokens, or adding additional parameters like the cookie admin=1 to the API call. You can also switch out the HTTP request methods, including GET, POST, PUT, PATCH, and DELETE, to see if access control is properly implemented across all methods. For example, if you can’t edit another user’s blog posts via a POST request to an API endpoint, can you bypass the protection by using a PUT request instead?

如果您的低权限用户无法访问受限功能，则可以尝试移除访问令牌或添加其他参数，比如添加 Cookie admin=1 到 API 调用中。您也可以更改 HTTP 请求方法，包括 GET、POST、PUT、PATCH 和 DELETE，以查看是否对所有方法正确实施访问控制。例如，如果您无法通过 POST 请求到 API 端点来编辑另一个用户的博客文章，那么您是否可以通过使用 PUT 请求来绕过保护？

Try to view, modify, and delete other users’ info by switching out user IDs or other user identification parameters found in the API calls. If IDs used to identify users and resources are unpredictable, try to leak IDs through info leaks from other endpoints. For example, I once found an API endpoint that returned user information; it revealed the user’s ID as well as all of the user’s friends’ IDs. With the ID of both the user and their friend, I was able to access messages sent between the two users. By combining two info leaks and using just the user IDs, I was able to read a user’s private messages!

尝试通过替换 API 调用中的用户 ID 或其他用户识别参数来查看、修改和删除其他用户的信息。如果用于识别用户和资源的 ID 不可预测，则尝试通过其他端点的信息泄漏来泄露 ID。例如，我曾经发现一个 API 端点返回用户信息；它显示了用户的 ID 以及所有用户朋友的 ID。有了用户和他们朋友的 ID，我就能够访问两个用户之间发送的消息。通过结合两个信息泄漏并仅使用用户 ID，我能够阅读用户的私人消息！

In GraphQL, a common misconfiguration is allowing lower-privileged users to modify a piece of data that they should not via a mutation request. Try to capture GraphQL queries allowed from one user’s account, and see if you can send the same query and achieve the same results from another who shouldn’t have permission.

在 GraphQL 中，常见的配置错误是允许权限较低的用户通过变异请求修改他们不应该具有权限的数据。尝试捕捉从一个用户帐户允许的 GraphQL 查询，并查看是否可以从另一个无权访问的用户发送相同的查询并实现相同的结果。

While hunting for access control issues, closely study the data being sent back by the server. Don’t just look at the resulting HTML page; dive into the raw API response, as APIs often return data that doesn’t get displayed on the web page. You might be able to find sensitive information disclosures in the response body. Is the API endpoint returning any private user information, or sensitive information about the organization? Should the returned information be available to the current user? Does the returned information pose a security risk to the company?

在查找访问控制问题时，密切研究服务器返回的数据。不要只看结果 HTML 页面，要深入了解原始 API 响应，因为 API 经常返回不会显示在网页上的数据。您可能会在响应正文中找到敏感信息披露。API 端点是否返回任何私人用户信息或关于组织的敏感信息？返回的信息是否应该提供给当前用户？返回的信息是否对公司构成安全风险？

Testing for Rate-Limiting Issues

APIs often lack rate limiting; in other words, the API server doesn’t restrict the number of requests a client or user account can send within a short time frame. A lack of rate limiting in itself is a low-severity vulnerability unless it’s proven to be exploitable by attackers. But on critical endpoints, a lack of rate limiting means that malicious users can send large numbers of requests to the server to harvest database information or brute-force credentials.

API 经常缺乏速率限制; 换句话说，API 服务器不会限制客户或用户帐户在短时间内可以发送的请求数量。缺乏速率限制本身是低严重性漏洞，除非攻击者证明可以利用它。但是在关键端点上，缺乏速率限制意味着恶意用户可以向服务器发送大量请求以收集数据库信息或暴力破解凭据。

Endpoints that can be dangerous when not rate limited include authentication endpoints, endpoints not protected by access control, and endpoints that return large amounts of sensitive data. For example, I once encountered an API endpoint that allows users to retrieve their emails via an email ID, like this:

如果没有速率限制，可能会危险的端点包括身份验证端点、没有访问控制保护的端点以及返回大量敏感数据的端点。例如，我曾经遇到过一个 API 端点，允许用户通过电子邮件 ID 检索他们的电子邮件，就像这样：

GET /api/v2/user_emails/    52603991338963203244

This endpoint isn’t protected by any access control. Since this endpoint isn’t rate limited, either, an attacker can essentially guess the email ID field by sending numerous requests. Once they’ve guessed a valid ID, they can access another user’s private email.

此端点没有任何访问控制保护。鉴于此端点没有速率限制，攻击者可以通过发送大量请求逐渐猜测电子邮件 ID 字段。一旦他们猜对了一个有效的 ID，他们就可以访问另一个用户的私人电子邮件。

To test for rate-limiting issues, make large numbers of requests to the endpoint. You can use the Burp intruder or curl to send 100 to 200 requests in a short time. Make sure you repeat the test in different authentication stages, because users with different privilege levels can be subject to different rate limits.

为了测试速率限制问题，请对端点进行大量请求。您可以使用 Burp Intruder 或 curl 在短时间内发送 100 到 200 个请求。请确保在不同的身份验证阶段重复测试，因为不同特权级别的用户可能会受到不同的速率限制。

Be really careful when you are testing for rate-limiting issues because it’s very possible to accidentally launch a DoS attack on the app by drowning it with requests. You should obtain written permission before conducting rate-limiting tests and time-throttle your requests according to the company’s policies.

在测试速率限制问题时一定要非常小心，因为很有可能意外地通过请求淹没应用程序来启动 DoS 攻击。在进行速率限制测试之前，您应该获得书面许可，并根据公司政策对请求进行时间节流。

Also keep in mind that applications could have rate limits that are higher than your testing tools’ capabilities. For instance, applications could set a rate limit of 400 requests a second, and your tooling may not be capable of reaching that limit.

请注意，应用程序可能设置比您的测试工具更高的速率限制。例如，应用程序可以设置每秒 400 个请求的速率限制，而您的工具可能无法达到这个限制。

Testing for Technical Bugs

Many of the bugs that we’ve discussed in this book so far—such as SQL injection, deserialization issues, XXEs, template injections, SSRF, and RCEs—are caused by improper input validation. Sometimes developers forget to implement proper input validation mechanisms for APIs.

我们这本书中所讨论的许多漏洞——例如 SQL 注入、反序列化问题、XXE、模板注入、SSRF 和 RCE 等——都是由于输入验证不当引起的。有时候，开发人员会忘记为 API 实现适当的输入验证机制。

APIs are therefore susceptible to many of the other vulnerabilities that affect regular web applications too. Since APIs are another way applications accept user input, they become another way for attackers to smuggle malicious input into the application’s workflow.

因此，API 也容易受到影响常规 Web 应用程序的许多其他漏洞的攻击。由于 API 是应用程序接受用户输入的另一种方式，因此它们成为攻击者将恶意输入走私到应用程序工作流程的另一种方式。

If an API endpoint can access external URLs, it might be vulnerable to SSRF, so you should check whether its access to internal URLs isn’t restricted. Race conditions can also happen within APIs. If you can use API endpoints to access application features affected by race conditions, these endpoints can become an alternative way to trigger the race condition.

如果 API 端点可以访问外部 URL，则可能容易受到 SSRF 攻击，因此应检查其对内部 URL 的访问是否受限。在 API 中也可能会出现竞争条件。如果您可以使用 API 端点访问受竞争条件影响的应用程序功能，则这些端点可以成为触发竞争条件的替代方式。

Other vulnerabilities, like path traversal, file inclusion, insecure deserialization issues, XXE, and XSS can also happen. If an API endpoint returns internal resources via a filepath, attackers might use that endpoint to read sensitive files stored on the server. If an API endpoint used for file uploads doesn’t limit the data type that users can upload, attackers might upload malicious files, such as web shells or other malware, to the server. APIs also commonly accept user input in serialized formats such as XML. In this case, insecure deserialization or XXEs can happen. RCEs via file upload or XXEs are commonly seen in API endpoints. Finally, if an API’s URL parameters are reflected in the response, attackers can use that API endpoint to trigger reflected XSS on victims’ browsers.

其他漏洞，如路径遍历、文件包含、不安全的反序列化问题、XXE 和 XSS 也可能发生。 如果 API 端点通过文件路径返回内部资源，则攻击者可能利用该端点读取存储在服务器上的敏感文件。 如果用于文件上传的 API 端点不限制用户可以上传的数据类型，则攻击者可能上传恶意文件（如 Web Shell 或其他恶意软件）到服务器。 API 通常还接受以序列化格式（如 XML）的用户输入。 在这种情况下，可能会发生不安全的反序列化或 XXE。 RCE 通过文件上传或 XXE 常见于 API 端点。 最后，如果 API 的 URL 参数在响应中反映出来，攻击者可以利用该 API 端点在受害者的浏览器上触发反射型 XSS。 其他漏洞包括，路径遍历、文件包含、不安全的反序化、XXE 和 XSS 可能会出现。当 API 端点返回文件路径的内部资源时，攻击者可能会利用该端点读取存储在服务器上的敏感文件。如果用户在用于文件上传的 API 端点没有限制上传的数据类型，攻击者可能会上传恶意文件，例如 Web Shell 或其他恶意软件，到服务器。API 还通常以序列化格式接受用户输入，如 XML。在这种情况下，可能会发生不安全的反序列化或 XXE。通过文件上传或 XXE 实现远程代码执行(RCE) 在 API 端点中很常见。最后，如果 API 的 URL 参数在响应中反映出来，攻击者可以利用该 API 端点，在受害者的浏览器上触发反射型 XSS。

The process of testing for these issues will be similar to testing for them in a regular web app. You’ll simply supply the payloads to the application in API form.

测试这些问题的过程将与在常规 Web 应用程序中测试它们的过程类似。您只需以 API 形式向应用程序提供有效负载即可。

For example, for vulnerabilities like path traversals and file-inclusion attacks, look out for absolute and relative filepaths in API endpoints and try to mess with the path parameters. If an API endpoint accepts XML input, try to insert an XXE payload into the request. And if the endpoint’s URL parameters are reflected in the response, see if you can trigger a reflected XSS by placing a payload in the URL.

例如，对于路径遍历和文件包含攻击等漏洞，要注意 API 端点中的绝对路径和相对路径，并尝试对路径参数进行干扰。如果 API 端点接受 XML 输入，请尝试在请求中插入 XXE 有效载荷。如果端点的 URL 参数在响应中反映出来，请尝试将有效载荷放在 URL 中触发反射型 XSS 攻击。

You can also utilize fuzz-testing techniques, which we’ll discuss in Chapter 25 , to find these vulnerabilities.

你也可以利用第 25 章将会介绍的“模糊测试”技术来发现这些漏洞。

Applications are becoming increasingly reliant on APIs, even as APIs aren’t always as well protected as their web application counterparts. Pay attention to the APIs used by your targets, and you might find issues not present in the main application. If you are interested in learning more about hacking APIs and web applications in general, the OWASP Web Security Testing Guide ( https://github.com/OWASP/wstg/ ) is a great resource to learn from.

应用程序越来越依赖 API，即使 API 并不总是像它们的 Web 应用程序对应物那样受到良好的保护。关注目标使用的 API，您可能会发现主应用程序中不存在的问题。如果您对学习 API 和 Web 应用程序的黑客技术感兴趣，OWASP Web 安全测试指南（https://github.com/OWASP/wstg/）是一个很好的学习资源。