According to the Wallarm Q1 2025 ThreatStats report, 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.
I recently sat down with AJ Debole, Field CISO at Oracle, for a practical, forward-looking discussion about why API security matters now more than ever – and how NIST SP 800-228 could be an all-important north star.
The Context: APIs, Automation, and Attack Velocity
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.
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.
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.
What NIST SP 800-228 Brings to the Table
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.
API Specification and Inventory Management
We started with the basics: you can’t protect what you don’t know exists. I pointed out that an up-to-date API inventory and well-defined specifications 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.
Schema Validation and Input Handling
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.
Authentication and Authorization
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 access controls, not just basic endpoint restrictions.
Sensitive Data Identification and Protection
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.
Access Control Hygiene and Request Flow
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.
Rate Limiting and Abuse Prevention
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 rate limits, not just per endpoint, but by method, user, or field – wherever abuse could occur.
Logging and Observability
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.
Where Wallarm Fits In
Wallarm aligns with NIST SP 800-228, 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).
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.
Want to find out more about NIST SP 800-228 and how Wallarm can help you comply? Check out the full webinar with me and AJ.
The post Addressing API Security with NIST SP 800-228 appeared first on Wallarm.