程序员征服安全 OWASP 十大 API 系列-缺乏资源和速率限制
由于缺乏资源和速率限制，API 漏洞的行为几乎完全符合标题的描述。每个 API 的可用资源和计算能力都有限，具体取决于其环境。大多数人还必须回答用户或其他程序的请求，要求其执行所需的功能。当同时传入的请求过多，且 API 没有足够的计算资源来处理这些请求时，就会出现此漏洞。然后，该 API 可能变得不可用或无法响应新请求。
如果 API 的速率或资源限制设置不正确，或者代码中未定义限制，则容易受到此问题的影响。例如，如果企业遇到特别繁忙的时期，则API可能会过载。但这也是一个安全漏洞，因为威胁行为者可以故意使用请求使未受保护的 API 过载，以执行拒绝服务 (DDoS) 攻击。
顺便问一下，到目前为止，你在 API 游戏化挑战中表现如何？如果你想立即尝试处理速率限制漏洞的技能，那就进入竞技场：
现在，让我们更深入地了解一下。
缺乏资源和速率限制 API 漏洞的一些例子有哪些？
此漏洞可以通过两种方式潜入 API。首先是编码人员根本没有定义API的油门速率应该是多少。基础设施中的某个地方可能有默认的油门费率设置，但依赖它并不是一个好政策。相反，每个 API 都应单独设置其费率。尤其如此，因为 API 可能具有截然不同的功能和可用资源。
例如，设计为仅为少数用户服务的内部 API 的油门速率可能非常低并且运行良好。但是，作为实时电子商务网站一部分的面向公众的API很可能需要定义极高的速率来弥补同时用户激增的可能性。在这两种情况下，节流速率都应根据预期需求、潜在用户数量和可用计算能力来定义。
为了最大限度地提高性能，将速率设置为无限可能会很诱人，尤其是在很可能非常繁忙的 API 中。这可以通过一段简单的代码来完成（例如，我们将使用 Python Django REST框架):
“默认节流速率：{
“不知道：没有，
“用户：无
在该示例中，匿名用户和系统已知用户都可以无限次地联系 API，而不考虑一段时间内的请求数量。这是个坏主意，因为无论API有多少可用的计算资源，攻击者都可以部署僵尸网络之类的东西，从而最终减慢其爬行速度，或者可能将其完全下线。发生这种情况时，有效用户将被拒绝访问，攻击将成功。
消除资源短缺和速率限制问题
组织部署的每个 API 都应在其代码中定义其限制率。这可能包括执行超时、最大允许内存、可以返回给用户的每页记录数或在定义的时间范围内允许的进程数量等内容。
从上面的示例中可以看出，与其完全开放限制速率，不如对匿名用户和已知用户使用不同的费率来严格定义节流速率。
“默认节流速率：{
“匿名：配置（“THROTTLE_ANON，默认值 = 200/小时），
“用户：配置（“THROTTLE_USER，默认值 = 5000/小时）
在新示例中，API 将限制匿名用户每小时发出 200 个请求。已通过系统审核的已知用户将获得更大的回旋余地，每小时 5,000 个请求。但是，即使它们也仅限于防止高峰时段意外过载，或者在用户帐户遭到入侵并被用于拒绝服务攻击时进行补偿。
作为最后要考虑的良好做法，最好在用户达到限制时向他们显示通知，并解释何时重置这些限制。这样，有效的用户就会知道应用程序拒绝他们的请求的原因。如果执行经批准的任务的有效用户被拒绝访问 API，这也会很有用，因为它可以向操作人员发出信号，表明需要加强限制。
来看看 安全代码勇士 博客页面，详细了解此漏洞以及如何保护您的组织和客户免受其他安全漏洞的破坏。你也可以 试试演示 Secure Code Warrior 培训平台可让您的所有网络安全技能不断磨练并保持最新状态。
当同时传入的请求过多，且 API 没有足够的计算资源来处理这些请求时，就会出现此漏洞。然后，该 API 可能变得不可用或无法响应新请求。
Matias Madou est expert en sécurité, chercheur, directeur technique et cofondateur de Secure Code Warrior. Matias a obtenu son doctorat en sécurité des applications à l'université de Gand, en se concentrant sur les solutions d'analyse statique. Il a ensuite rejoint Fortify aux États-Unis, où il s'est rendu compte qu'il ne suffisait pas de détecter les problèmes de code sans aider les développeurs à écrire du code sécurisé. C'est ce qui l'a incité à développer des produits qui aident les développeurs, allègent le fardeau de la sécurité et dépassent les attentes des clients. Lorsqu'il n'est pas à son bureau en tant que membre de l'équipe Awesome, il aime être sur scène pour présenter des conférences, notamment RSA Conference, BlackHat et DefCon.
Secure Code Warrior peut aider votre organisation à sécuriser le code tout au long du cycle de vie du développement logiciel et à instaurer une culture qui accorde la priorité à la cybersécurité. Que vous soyez responsable de la sécurité des applications, développeur, directeur de la sécurité de l'information ou tout autre professionnel concerné par la sécurité, nous pouvons aider votre organisation à réduire les risques liés au code non sécurisé.
Veuillez réserver une démonstration.
Matias Madou est expert en sécurité, chercheur, directeur technique et cofondateur de Secure Code Warrior. Matias a obtenu son doctorat en sécurité des applications à l'université de Gand, en se concentrant sur les solutions d'analyse statique. Il a ensuite rejoint Fortify aux États-Unis, où il s'est rendu compte qu'il ne suffisait pas de détecter les problèmes de code sans aider les développeurs à écrire du code sécurisé. C'est ce qui l'a incité à développer des produits qui aident les développeurs, allègent le fardeau de la sécurité et dépassent les attentes des clients. Lorsqu'il n'est pas à son bureau en tant que membre de l'équipe Awesome, il aime être sur scène pour présenter des conférences, notamment RSA Conference, BlackHat et DefCon.
Matias est un chercheur et un développeur qui possède plus de 15 ans d'expérience pratique dans le domaine de la sécurité des logiciels. Il a développé des solutions pour des entreprises telles que Fortify Software et sa propre entreprise Sensei Security. Au cours de sa carrière, Matias a dirigé de nombreux projets de recherche sur la sécurité des applications qui ont débouché sur des produits commerciaux et peut se targuer d'avoir déposé plus de 10 brevets. Lorsqu'il n'est pas à son bureau, Matias a été instructeur pour des formations avancées en matière de sécurité des applications ( courses ) et intervient régulièrement lors de conférences mondiales telles que RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec et BruCon.
Matias est titulaire d'un doctorat en ingénierie informatique de l'Université de Gand, où il a étudié la sécurité des applications par le biais de l'obscurcissement des programmes afin de dissimuler le fonctionnement interne d'une application.
由于缺乏资源和速率限制，API 漏洞的行为几乎完全符合标题的描述。每个 API 的可用资源和计算能力都有限，具体取决于其环境。大多数人还必须回答用户或其他程序的请求，要求其执行所需的功能。当同时传入的请求过多，且 API 没有足够的计算资源来处理这些请求时，就会出现此漏洞。然后，该 API 可能变得不可用或无法响应新请求。
如果 API 的速率或资源限制设置不正确，或者代码中未定义限制，则容易受到此问题的影响。例如，如果企业遇到特别繁忙的时期，则API可能会过载。但这也是一个安全漏洞，因为威胁行为者可以故意使用请求使未受保护的 API 过载，以执行拒绝服务 (DDoS) 攻击。
顺便问一下，到目前为止，你在 API 游戏化挑战中表现如何？如果你想立即尝试处理速率限制漏洞的技能，那就进入竞技场：
现在，让我们更深入地了解一下。
缺乏资源和速率限制 API 漏洞的一些例子有哪些？
此漏洞可以通过两种方式潜入 API。首先是编码人员根本没有定义API的油门速率应该是多少。基础设施中的某个地方可能有默认的油门费率设置，但依赖它并不是一个好政策。相反，每个 API 都应单独设置其费率。尤其如此，因为 API 可能具有截然不同的功能和可用资源。
例如，设计为仅为少数用户服务的内部 API 的油门速率可能非常低并且运行良好。但是，作为实时电子商务网站一部分的面向公众的API很可能需要定义极高的速率来弥补同时用户激增的可能性。在这两种情况下，节流速率都应根据预期需求、潜在用户数量和可用计算能力来定义。
为了最大限度地提高性能，将速率设置为无限可能会很诱人，尤其是在很可能非常繁忙的 API 中。这可以通过一段简单的代码来完成（例如，我们将使用 Python Django REST框架):
“默认节流速率：{
“不知道：没有，
“用户：无
在该示例中，匿名用户和系统已知用户都可以无限次地联系 API，而不考虑一段时间内的请求数量。这是个坏主意，因为无论API有多少可用的计算资源，攻击者都可以部署僵尸网络之类的东西，从而最终减慢其爬行速度，或者可能将其完全下线。发生这种情况时，有效用户将被拒绝访问，攻击将成功。
消除资源短缺和速率限制问题
组织部署的每个 API 都应在其代码中定义其限制率。这可能包括执行超时、最大允许内存、可以返回给用户的每页记录数或在定义的时间范围内允许的进程数量等内容。
从上面的示例中可以看出，与其完全开放限制速率，不如对匿名用户和已知用户使用不同的费率来严格定义节流速率。
“默认节流速率：{
“匿名：配置（“THROTTLE_ANON，默认值 = 200/小时），
“用户：配置（“THROTTLE_USER，默认值 = 5000/小时）
在新示例中，API 将限制匿名用户每小时发出 200 个请求。已通过系统审核的已知用户将获得更大的回旋余地，每小时 5,000 个请求。但是，即使它们也仅限于防止高峰时段意外过载，或者在用户帐户遭到入侵并被用于拒绝服务攻击时进行补偿。
作为最后要考虑的良好做法，最好在用户达到限制时向他们显示通知，并解释何时重置这些限制。这样，有效的用户就会知道应用程序拒绝他们的请求的原因。如果执行经批准的任务的有效用户被拒绝访问 API，这也会很有用，因为它可以向操作人员发出信号，表明需要加强限制。
来看看 安全代码勇士 博客页面，详细了解此漏洞以及如何保护您的组织和客户免受其他安全漏洞的破坏。你也可以 试试演示 Secure Code Warrior 培训平台可让您的所有网络安全技能不断磨练并保持最新状态。
由于缺乏资源和速率限制，API 漏洞的行为几乎完全符合标题的描述。每个 API 的可用资源和计算能力都有限，具体取决于其环境。大多数人还必须回答用户或其他程序的请求，要求其执行所需的功能。当同时传入的请求过多，且 API 没有足够的计算资源来处理这些请求时，就会出现此漏洞。然后，该 API 可能变得不可用或无法响应新请求。
如果 API 的速率或资源限制设置不正确，或者代码中未定义限制，则容易受到此问题的影响。例如，如果企业遇到特别繁忙的时期，则API可能会过载。但这也是一个安全漏洞，因为威胁行为者可以故意使用请求使未受保护的 API 过载，以执行拒绝服务 (DDoS) 攻击。
顺便问一下，到目前为止，你在 API 游戏化挑战中表现如何？如果你想立即尝试处理速率限制漏洞的技能，那就进入竞技场：
现在，让我们更深入地了解一下。
缺乏资源和速率限制 API 漏洞的一些例子有哪些？
此漏洞可以通过两种方式潜入 API。首先是编码人员根本没有定义API的油门速率应该是多少。基础设施中的某个地方可能有默认的油门费率设置，但依赖它并不是一个好政策。相反，每个 API 都应单独设置其费率。尤其如此，因为 API 可能具有截然不同的功能和可用资源。
例如，设计为仅为少数用户服务的内部 API 的油门速率可能非常低并且运行良好。但是，作为实时电子商务网站一部分的面向公众的API很可能需要定义极高的速率来弥补同时用户激增的可能性。在这两种情况下，节流速率都应根据预期需求、潜在用户数量和可用计算能力来定义。
为了最大限度地提高性能，将速率设置为无限可能会很诱人，尤其是在很可能非常繁忙的 API 中。这可以通过一段简单的代码来完成（例如，我们将使用 Python Django REST框架):
“默认节流速率：{
“不知道：没有，
“用户：无
在该示例中，匿名用户和系统已知用户都可以无限次地联系 API，而不考虑一段时间内的请求数量。这是个坏主意，因为无论API有多少可用的计算资源，攻击者都可以部署僵尸网络之类的东西，从而最终减慢其爬行速度，或者可能将其完全下线。发生这种情况时，有效用户将被拒绝访问，攻击将成功。
消除资源短缺和速率限制问题
组织部署的每个 API 都应在其代码中定义其限制率。这可能包括执行超时、最大允许内存、可以返回给用户的每页记录数或在定义的时间范围内允许的进程数量等内容。
从上面的示例中可以看出，与其完全开放限制速率，不如对匿名用户和已知用户使用不同的费率来严格定义节流速率。
“默认节流速率：{
“匿名：配置（“THROTTLE_ANON，默认值 = 200/小时），
“用户：配置（“THROTTLE_USER，默认值 = 5000/小时）
在新示例中，API 将限制匿名用户每小时发出 200 个请求。已通过系统审核的已知用户将获得更大的回旋余地，每小时 5,000 个请求。但是，即使它们也仅限于防止高峰时段意外过载，或者在用户帐户遭到入侵并被用于拒绝服务攻击时进行补偿。
作为最后要考虑的良好做法，最好在用户达到限制时向他们显示通知，并解释何时重置这些限制。这样，有效的用户就会知道应用程序拒绝他们的请求的原因。如果执行经批准的任务的有效用户被拒绝访问 API，这也会很有用，因为它可以向操作人员发出信号，表明需要加强限制。
来看看 安全代码勇士 博客页面，详细了解此漏洞以及如何保护您的组织和客户免受其他安全漏洞的破坏。你也可以 试试演示 Secure Code Warrior 培训平台可让您的所有网络安全技能不断磨练并保持最新状态。
Veuillez cliquer sur le lien ci-dessous pour télécharger le PDF de cette ressource.
Secure Code Warrior peut aider votre organisation à sécuriser le code tout au long du cycle de vie du développement logiciel et à instaurer une culture qui accorde la priorité à la cybersécurité. Que vous soyez responsable de la sécurité des applications, développeur, directeur de la sécurité de l'information ou tout autre professionnel concerné par la sécurité, nous pouvons aider votre organisation à réduire les risques liés au code non sécurisé.
Veuillez consulter le rapport.Veuillez réserver une démonstration.
Matias Madou est expert en sécurité, chercheur, directeur technique et cofondateur de Secure Code Warrior. Matias a obtenu son doctorat en sécurité des applications à l'université de Gand, en se concentrant sur les solutions d'analyse statique. Il a ensuite rejoint Fortify aux États-Unis, où il s'est rendu compte qu'il ne suffisait pas de détecter les problèmes de code sans aider les développeurs à écrire du code sécurisé. C'est ce qui l'a incité à développer des produits qui aident les développeurs, allègent le fardeau de la sécurité et dépassent les attentes des clients. Lorsqu'il n'est pas à son bureau en tant que membre de l'équipe Awesome, il aime être sur scène pour présenter des conférences, notamment RSA Conference, BlackHat et DefCon.
Matias est un chercheur et un développeur qui possède plus de 15 ans d'expérience pratique dans le domaine de la sécurité des logiciels. Il a développé des solutions pour des entreprises telles que Fortify Software et sa propre entreprise Sensei Security. Au cours de sa carrière, Matias a dirigé de nombreux projets de recherche sur la sécurité des applications qui ont débouché sur des produits commerciaux et peut se targuer d'avoir déposé plus de 10 brevets. Lorsqu'il n'est pas à son bureau, Matias a été instructeur pour des formations avancées en matière de sécurité des applications ( courses ) et intervient régulièrement lors de conférences mondiales telles que RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec et BruCon.
Matias est titulaire d'un doctorat en ingénierie informatique de l'Université de Gand, où il a étudié la sécurité des applications par le biais de l'obscurcissement des programmes afin de dissimuler le fonctionnement interne d'une application.
由于缺乏资源和速率限制，API 漏洞的行为几乎完全符合标题的描述。每个 API 的可用资源和计算能力都有限，具体取决于其环境。大多数人还必须回答用户或其他程序的请求，要求其执行所需的功能。当同时传入的请求过多，且 API 没有足够的计算资源来处理这些请求时，就会出现此漏洞。然后，该 API 可能变得不可用或无法响应新请求。
如果 API 的速率或资源限制设置不正确，或者代码中未定义限制，则容易受到此问题的影响。例如，如果企业遇到特别繁忙的时期，则API可能会过载。但这也是一个安全漏洞，因为威胁行为者可以故意使用请求使未受保护的 API 过载，以执行拒绝服务 (DDoS) 攻击。
顺便问一下，到目前为止，你在 API 游戏化挑战中表现如何？如果你想立即尝试处理速率限制漏洞的技能，那就进入竞技场：
现在，让我们更深入地了解一下。
缺乏资源和速率限制 API 漏洞的一些例子有哪些？
此漏洞可以通过两种方式潜入 API。首先是编码人员根本没有定义API的油门速率应该是多少。基础设施中的某个地方可能有默认的油门费率设置，但依赖它并不是一个好政策。相反，每个 API 都应单独设置其费率。尤其如此，因为 API 可能具有截然不同的功能和可用资源。
例如，设计为仅为少数用户服务的内部 API 的油门速率可能非常低并且运行良好。但是，作为实时电子商务网站一部分的面向公众的API很可能需要定义极高的速率来弥补同时用户激增的可能性。在这两种情况下，节流速率都应根据预期需求、潜在用户数量和可用计算能力来定义。
为了最大限度地提高性能，将速率设置为无限可能会很诱人，尤其是在很可能非常繁忙的 API 中。这可以通过一段简单的代码来完成（例如，我们将使用 Python Django REST框架):
“默认节流速率：{
“不知道：没有，
“用户：无
在该示例中，匿名用户和系统已知用户都可以无限次地联系 API，而不考虑一段时间内的请求数量。这是个坏主意，因为无论API有多少可用的计算资源，攻击者都可以部署僵尸网络之类的东西，从而最终减慢其爬行速度，或者可能将其完全下线。发生这种情况时，有效用户将被拒绝访问，攻击将成功。
消除资源短缺和速率限制问题
组织部署的每个 API 都应在其代码中定义其限制率。这可能包括执行超时、最大允许内存、可以返回给用户的每页记录数或在定义的时间范围内允许的进程数量等内容。
从上面的示例中可以看出，与其完全开放限制速率，不如对匿名用户和已知用户使用不同的费率来严格定义节流速率。
“默认节流速率：{
“匿名：配置（“THROTTLE_ANON，默认值 = 200/小时），
“用户：配置（“THROTTLE_USER，默认值 = 5000/小时）
在新示例中，API 将限制匿名用户每小时发出 200 个请求。已通过系统审核的已知用户将获得更大的回旋余地，每小时 5,000 个请求。但是，即使它们也仅限于防止高峰时段意外过载，或者在用户帐户遭到入侵并被用于拒绝服务攻击时进行补偿。
作为最后要考虑的良好做法，最好在用户达到限制时向他们显示通知，并解释何时重置这些限制。这样，有效的用户就会知道应用程序拒绝他们的请求的原因。如果执行经批准的任务的有效用户被拒绝访问 API，这也会很有用，因为它可以向操作人员发出信号，表明需要加强限制。
来看看 安全代码勇士 博客页面，详细了解此漏洞以及如何保护您的组织和客户免受其他安全漏洞的破坏。你也可以 试试演示 Secure Code Warrior 培训平台可让您的所有网络安全技能不断磨练并保持最新状态。
Table des matières
Matias Madou est expert en sécurité, chercheur, directeur technique et cofondateur de Secure Code Warrior. Matias a obtenu son doctorat en sécurité des applications à l'université de Gand, en se concentrant sur les solutions d'analyse statique. Il a ensuite rejoint Fortify aux États-Unis, où il s'est rendu compte qu'il ne suffisait pas de détecter les problèmes de code sans aider les développeurs à écrire du code sécurisé. C'est ce qui l'a incité à développer des produits qui aident les développeurs, allègent le fardeau de la sécurité et dépassent les attentes des clients. Lorsqu'il n'est pas à son bureau en tant que membre de l'équipe Awesome, il aime être sur scène pour présenter des conférences, notamment RSA Conference, BlackHat et DefCon.
Secure Code Warrior peut aider votre organisation à sécuriser le code tout au long du cycle de vie du développement logiciel et à instaurer une culture qui accorde la priorité à la cybersécurité. Que vous soyez responsable de la sécurité des applications, développeur, directeur de la sécurité de l'information ou tout autre professionnel concerné par la sécurité, nous pouvons aider votre organisation à réduire les risques liés au code non sécurisé.
Veuillez réserver une démonstration.TéléchargerRessources pour vous aider à démarrer
Formation sur les codes de sécurité : thèmes et contenu
Notre contenu de pointe évolue constamment pour s'adapter au paysage changeant du développement logiciel, tout en tenant compte de votre rôle. Les sujets abordés couvrent tout, de l'IA à l'injection XQuery, et s'adressent à divers postes, des architectes et ingénieurs aux chefs de produit et responsables de l'assurance qualité. Découvrez un aperçu par thème et par rôle de ce que notre catalogue de contenu a à offrir.
La Chambre de commerce établit la norme en matière de sécurité à grande échelle axée sur les développeurs
La Chambre de commerce néerlandaise explique comment elle a intégré le codage sécurisé dans le développement quotidien grâce à des certifications basées sur les rôles, à l'évaluation comparative du Trust Score et à une culture de responsabilité partagée en matière de sécurité.
%20(1).avif)
.avif)
Modélisation des menaces avec l'IA : transformer chaque développeur en modélisateur de menaces
Vous repartirez mieux équipé pour aider les développeurs à combiner les idées et les techniques de modélisation des menaces avec les outils d'IA qu'ils utilisent déjà pour renforcer la sécurité, améliorer la collaboration et créer des logiciels plus résilients dès le départ.
Ressources pour vous aider à démarrer
Cybermon est de retour : la mission AI pour vaincre le boss est désormais disponible sur demande.
Cybermon 2025 : la campagne « Vaincre le boss » est désormais disponible toute l'année dans SCW. La guerre de sécurité avancée de l'IA/LLM tribale, le renforcement de l'IA de sécurité à grande échelle.
Interprétation de la loi sur la résilience des réseaux : que signifie la sécurité par le biais de la conception et du développement de logiciels ?
Comprenez les exigences de la loi européenne sur la résilience des réseaux (CRA), à qui elle s'applique et comment les équipes d'ingénierie peuvent s'y préparer grâce à des pratiques de conception, à la prévention des vulnérabilités et au renforcement des capacités des développeurs.
Facteur déterminant 1 : des critères de réussite clairs et mesurables
Le catalyseur n° 1 constitue le premier volet de notre série en dix parties consacrée aux facteurs de réussite. Il démontre comment relier la sécurité du code aux résultats opérationnels, tels que la réduction des risques et l'accélération de la maturité des programmes à long terme.
