Addressing API Security with NIST SP 800-228
None
<p>According to the Wallarm <a href="https://www.wallarm.com/reports/q1-2025-wallarm-api-threatstats-report" rel="noreferrer noopener">Q1 2025 ThreatStats report</a>, 70% of all application attacks target APIs. The industry can no longer treat API security as a sidenote; it’s time to treat it as the main event. NIST seems to be on board with this view, releasing the initial public draft of NIST SP 800-228, a set of recommendations for securing APIs. </p><p>I recently sat down with <a href="https://www.linkedin.com/in/ajdebole/" rel="noreferrer noopener">AJ Debole</a>, Field CISO at Oracle, for a practical, forward-looking discussion about why API security matters now more than ever – and how <a href="https://lab.wallarm.com/meeting-nist-api-security-guidelines-with-wallarm/" rel="noreferrer noopener">NIST SP 800-228</a> could be an all-important north star. </p><h2 class="wp-block-heading">The Context: APIs, Automation, and Attack Velocity</h2><p>APIs aren’t just an evolution of application architecture; they’re a fundamental shift in how services are built, consumed, and secured. Unlike web applications, APIs are designed for programmatic access. That means the same traits that make them essential for automation – statefulness, structure, machine readability – also make them attractive to attackers. </p><div class="code-block code-block-12 ai-track" data-ai="WzEyLCIiLCJCbG9jayAxMiIsIiIsMV0=" style="margin: 8px 0; clear: both;"> <style> .ai-rotate {position: relative;} .ai-rotate-hidden {visibility: hidden;} .ai-rotate-hidden-2 {position: absolute; top: 0; left: 0; width: 100%; height: 100%;} .ai-list-data, .ai-ip-data, .ai-filter-check, .ai-fallback, .ai-list-block, .ai-list-block-ip, .ai-list-block-filter {visibility: hidden; position: absolute; width: 50%; height: 1px; top: -1000px; z-index: -9999; margin: 0px!important;} .ai-list-data, .ai-ip-data, .ai-filter-check, .ai-fallback {min-width: 1px;} </style> <div class="ai-rotate ai-unprocessed ai-timed-rotation ai-12-1" data-info="WyIxMi0xIiwyXQ==" style="position: relative;"> <div class="ai-rotate-option" style="visibility: hidden;" data-index="1" data-name="VGVjaHN0cm9uZyBHYW5nIFlvdXR1YmU=" data-time="MTA="> <div class="custom-ad"> <div style="margin: auto; text-align: center;"><a href="https://youtu.be/Fojn5NFwaw8" target="_blank"><img src="https://securityboulevard.com/wp-content/uploads/2024/12/Techstrong-Gang-Youtube-PodcastV2-770.png" alt="Techstrong Gang Youtube"></a></div> <div class="clear-custom-ad"></div> </div></div> <div class="ai-rotate-option" style="visibility: hidden; position: absolute; top: 0; left: 0; width: 100%; height: 100%;" data-index="1" data-name="QVdTIEh1Yg==" data-time="MTA="> <div class="custom-ad"> <div style="margin: auto; text-align: center;"><a href="https://devops.com/builder-community-hub/?ref=in-article-ad-1&utm_source=do&utm_medium=referral&utm_campaign=in-article-ad-1" target="_blank"><img src="https://devops.com/wp-content/uploads/2024/10/Gradient-1.png" alt="AWS Hub"></a></div> <div class="clear-custom-ad"></div> </div></div> </div> </div><p>AJ raised an important point in our discussion: APIs lower the technical barrier to entry for offensive security work. You don’t need to manipulate browser traffic or master proxy tooling to fuzz an API; a simple curl command or Python script can be enough. That ease of access makes APIs a high-value target for both automated scanners and more sophisticated actors. </p><p>The increasing integration of APIs with AI systems (GenAI agents, in particular) only amplifies this risk. These agents interact with APIs autonomously, making decisions and triggering workflows. As a result, API traffic, complexity, and the risk of exposure have grown exponentially. </p><div class="code-block code-block-15" style="margin: 8px 0; clear: both;"> <script async src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js?client=ca-pub-2091799172090865" crossorigin="anonymous" type="ca078ff23a3ed0b32bcde234-text/javascript"></script> <!-- SB In Article Ad 1 --> <ins class="adsbygoogle" style="display:block" data-ad-client="ca-pub-2091799172090865" data-ad-slot="8723094367" data-ad-format="auto" data-full-width-responsive="true"></ins> <script type="ca078ff23a3ed0b32bcde234-text/javascript"> (adsbygoogle = window.adsbygoogle || []).push({}); </script></div><figure class="wp-block-image"><img data-recalc-dims="1" decoding="async" src="https://i0.wp.com/lab.wallarm.com/wp-content/uploads/2025/05/AD_4nXdZL9xSekfPeu_06OYQR24XyWBuxSz5JrC_ExiOwPBCD_LrQNxtSuywvcNhHvAVV-WdBnH242E-2szxH6u-NyB83Zu5EXTEXmg9hNbx0WcpVN3TbD4r6X-u_j7-HMVC4yFGeE_fmMXjXVVS6wJzAuQkeyYQatJVOOSJGD5qHpEj6NYA.jpg?w=770&ssl=1" alt=""></figure><h2 class="wp-block-heading">What NIST SP 800-228 Brings to the Table</h2><p>As is typical, NIST didn’t exactly hand us a tidy list of grouped best practices. They released 22 recommended controls. While we suggest looking through them yourself, though they can be a bit overwhelming to digest as a whole. So, during the webinar, AJ and I decided to do everyone a favor: we sorted them into seven thematic groups. These are not official categories, but a helpful lens for making sense of what’s there and how to apply it. </p><h3 class="wp-block-heading">API Specification and Inventory Management </h3><p>We started with the basics: you can’t protect what you don’t know exists. I pointed out that an up-to-date <a href="https://www.wallarm.com/solutions/discover-all-apis" rel="noreferrer noopener">API inventory</a> and well-defined <a href="https://lab.wallarm.com/api-specifications-why-when-how-to-enforce-them/" rel="noreferrer noopener">specifications</a> are foundational. AJ agreed, comparing the situation to old-school NACs. If we struggled to track physical devices, she said, tracking fact-moving, ephemeral APIs is going to be even tougher. Still, it’s essential to prevent shadow APIs from becoming low-hanging fruit. </p><h3 class="wp-block-heading">Schema Validation and Input Handling</h3><p>Once you know what’s there, you need to validate what’s coming through it. I talked about the importance of enforcing request/response schemas at runtime, and AJ shared a great example of a researcher exploiting a crypto exchange – not by changing the price, but by swapping out a token type the API didn’t properly validate. It’s a perfect illustration of why schema enforcement matters beyond the obvious inputs. </p><h3 class="wp-block-heading">Authentication and Authorization </h3><p>We both agreed: while authN has improved thanks to SSO and OAuth, authZ remains a mess. AJ put it bluntly: many APIs still let users “just say they’re an admin,” with no real checks. I added that these kinds of failures often go undetected; they don’t crash systems or encrypt files, they quietly leak data. That’s precisely why NIST calls for field- and method-level <a href="https://lab.wallarm.com/api-security-challenge-ai-resource-exhaustion-unauthorized-access/" rel="noreferrer noopener">access controls</a>, not just basic endpoint restrictions.</p><h3 class="wp-block-heading">Sensitive Data Identification and Protection</h3><p>Sensitive data isn’t just PII. AJ told a story about a company that accidentally exposed its cyber insurance policy online – which included the ransomware payout limit. That was all the attackers needed to ask for just the right amount of ransom. I emphasized that detecting and classifying data flowing through APIs, then enforcing policy around it, needs to go beyond simple patterns or keywords. </p><h3 class="wp-block-heading">Access Control Hygiene and Request Flow </h3><p>Here, we focused on hardening API behavior, especially in the case of compromised tokens or abnormal usage. I highlighted the recommendation to block specific keys or users on demand, and AJ pointed out that while that sounds straightforward, many organizations don’t yet have the tooling or processes to do it fast enough. NIST is clearly nudging the industry towards more mature, real-time response capabilities. </p><h3 class="wp-block-heading">Rate Limiting and Abuse Prevention</h3><p>APIs don’t just present availability risks, they can hit your wallet, too. AJ mentioned how attackers in cloud environments rack up massive bills by spinning up compute resource, and I noted it’s the same with LLMs or other metered APIs. NIST recommends granular <a href="https://www.wallarm.com/what/rate-limiting" rel="noreferrer noopener">rate limits</a>, not just per endpoint, but by method, user, or field – wherever abuse could occur. </p><h3 class="wp-block-heading">Logging and Observability</h3><p>Finally, we talked about observability. AJ made a strong point: having logs is one thing, but being able to respond is what counts. “Do you know what token was abused? Can you actually shut it down?” she asked. I agreed – without operational muscle and cross-team coordination, logs are just noise. NIST rightly includes visibility, but the real power comes when you tie that visibility to action. </p><h2 class="wp-block-heading">Where Wallarm Fits In</h2><p>Wallarm aligns with <a href="https://csrc.nist.gov/pubs/sp/800/228/ipd" rel="noreferrer noopener">NIST SP 800-228</a>, but provides direct API security controls (discovery, schema enforcement), validates API conformance (detecting non-compliant requests), and supports other security controls (identifying broken authentication, classifying sensitive data). </p><p>Our platform auto-discovers and inventories APIs, generates OpenAPI specs from live traffic to identify drift and shadow endpoints, and enforces schema validation. We also detect critical risks like broken authentication, exposed secrets, and BOLA, while surfacing sensitive data for policy enforcement and redaction. Additionally, Wallarm offers granular rate limiting and provides full traffic context for a complete attack narrative. </p><p>Want to find out more about NIST SP 800-228 and how Wallarm can help you comply? <a href="https://www.wallarm.com/webinars/addressing-api-security" rel="noreferrer noopener">Check out the full webinar with me and AJ</a>.</p><p>The post <a href="https://lab.wallarm.com/addressing-api-security-with-nist-sp-800-228/">Addressing API Security with NIST SP 800-228</a> appeared first on <a href="https://lab.wallarm.com/">Wallarm</a>.</p><div class="spu-placeholder" style="display:none"></div><p class="syndicated-attribution">*** This is a Security Bloggers Network syndicated blog from <a href="https://lab.wallarm.com/">Wallarm</a> authored by <a href="https://securityboulevard.com/author/0/" title="Read other posts by Tim Erlin">Tim Erlin</a>. Read the original post at: <a href="https://lab.wallarm.com/addressing-api-security-with-nist-sp-800-228/">https://lab.wallarm.com/addressing-api-security-with-nist-sp-800-228/</a> </p>