<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>API Security on API Coding</title>
    <link>https://apicoding.com/tags/api-security/</link>
    <description>Recent content in API Security on API Coding</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Mon, 16 Feb 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://apicoding.com/tags/api-security/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>OWASP API Security Top 10: The Vulnerabilities Shipping in Production Right Now</title>
      <link>https://apicoding.com/2026/02/16/owasp-api-security-top-10-the-vulnerabilities-shipping-in-production-right-now/</link>
      <pubDate>Mon, 16 Feb 2026 00:00:00 +0000</pubDate>
      <guid>https://apicoding.com/2026/02/16/owasp-api-security-top-10-the-vulnerabilities-shipping-in-production-right-now/</guid>
      <description>&lt;p&gt;The OWASP API Security Top 10 is updated periodically based on analysis of real API vulnerabilities in production systems. The list is not theoretical. The vulnerabilities it documents are the ones that security researchers find in bug bounty programs, that appear in breach disclosures, and that affect applications built by teams that considered security during development. Their persistence on the list across multiple editions reflects the difficulty of eliminating them in complex systems, not a lack of awareness that they exist.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Rate Limiting Is Not Optional and Most Implementations Are Wrong</title>
      <link>https://apicoding.com/2025/10/20/rate-limiting-is-not-optional-and-most-implementations-are-wrong/</link>
      <pubDate>Mon, 20 Oct 2025 00:00:00 +0000</pubDate>
      <guid>https://apicoding.com/2025/10/20/rate-limiting-is-not-optional-and-most-implementations-are-wrong/</guid>
      <description>&lt;p&gt;Rate limiting is one of the few API design decisions where the failure mode is existential rather than merely inconvenient. An API without rate limiting is an API that can be brought down by a single misbehaving consumer, whether that consumer is a customer with a buggy retry loop, a competitor running a data extraction operation, or an attacker attempting a denial of service. The argument for implementing rate limiting is not about fairness or monetization tiers, though it serves both. It is about operational survival.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
