NIST API Security Best Practices

Introduction

Modern enterprise infrastructure is API‑driven. NIST observed that today’s information‑technology systems depend on families of APIs to integrate business processes, and “secure development and deployment of APIs is critical for overall enterprise security”. The draft special publication SP 800‑228 aims to turn scattered tribal knowledge into a structured API‑security framework.

The urgency is evident in recent data. A 2025 API Security Impact Study found that 85 % of enterprises in the Asia-Pacific experienced an API‑related incident in the previous year, at an average cost exceeding US$580,000. Other analyses report that nearly all organizations encountered API security problems and that 84 % of security professionals suffered an API incident despite having dedicated resources. Vulnerability counts are rising: Bugcrowd data show hardware weaknesses climbed 88% and API vulnerabilities grew 10% year over year, while broken access control issues increased 40%.  APIs are also the weak link in AI deployments. IBM’s 2025 Cost of a Data Breach report notes that 97 % of AI‑related breaches lacked proper API access controls and that 98.9 % of AI‑related vulnerabilities were API‑related; 89 % involved weak authentication. 20% of organizations suffered breaches tied to shadow AI, and those incidents cost US$670,000 more on average. 

The financial stakes are high everywhere: the United States recorded average API remediation costs of about US$591,404 per incident, and incidents involving third‑party APIs often took months to resolve. As a result, the API security market is booming, with a value of US$11.62 billion in 2025 and a projected compound annual growth rate of 17.39 % through 2033. The banking, healthcare, and government sectors are driving adoption due to strict data‑protection requirements. 

With APIs powering everything from mobile banking to connected vehicles, these statistics underscore why boards, CEOs and CISOs must view API security as a strategic priority and leverage NIST’s guidelines to protect their digital ecosystems.

What is NIST API Security

The National Institute of Standards and Technology’s draft Special Publication 800‑228 is a full life‑cycle framework for protecting APIs. It recognizes that modern, microservice‑based systems depend on APIs and therefore extends zero‑trust principles to these interfaces by recommending that enforcement be applied as close as possible to each service instance and that both service and user identities be authenticated. The guidelines cover the design, development, deployment, runtime, and retirement of APIs, and divide controls into two stages: pre‑runtime (during design and build) and runtime (when the API is live). At the design stage, organizations must maintain a complete inventory and specification for every API  documenting owners, schemas and security requirements, to achieve visibility and prevent unknown “shadow APIs”.

‍

When APIs are in operation, SP 800‑228 mandates a layered defense. Core runtime measures include strong authentication and fine‑grained authorization using standardized tokens and mutual TLS, strict input and output validation against defined schemas to block malformed or malicious requests, and rate limiting and throttling to prevent resource exhaustion attacks. Continuous telemetry and logging are essential so teams can monitor who is calling each API, whether requests are blocked, and how the system is performing, while additional protections, such as web application firewalls, bot detection, and distributed denial‑of‑service mitigation, filter out abusive traffic. For mature programs, the guideline proposes advanced measures like blocking specific users or tokens, dynamically masking sensitive fields and using machine‑learning‑based anomaly detection. Together, these controls create a structured, risk‑based approach to API security that scales from basic safeguards to sophisticated protections.

Adopting NIST controls is not about ticking a compliance box; it’s about preventing the incidents that are costing organizations hundreds of thousands of dollars. 

Why NIST Matters for API Security 

Modern digital businesses run on APIs, yet the attack surface has exploded with microservices, mobile apps, and AI‑powered endpoints. NIST’s guidance recognises that reality: it spans the entire API lifecycle from design through deployment. 

Adopting NIST controls is not about ticking a compliance box; it’s about preventing the incidents that are costing organizations hundreds of thousands of dollars, and the reasons listed below help to emphasize that point: 

1. A unified, trusted framework: NIST consolidates years of scattered API‑security lore into one consistent playbook. SP 800‑228 walks through the entire API lifecycle,from design to retirement, so business, security and development teams can finally speak the same language about risks and mitigations.

2. Focus on today’s threats: The guidance doesn’t just echo general best practices; it calls out the vulnerabilities executives worry about most: untracked “shadow APIs,” missing or weak authorization and authentication, uncontrolled resource consumption and even generative‑AI misuse. By naming those issues, NIST helps leadership direct budget and attention to the correct problems.

3. Zero‑trust at the core: SP 800‑228 embraces zero‑trust principles, requiring that both the calling service and the end user verify their identities. It promotes proven standards such as OAuth, SAML and mutual TLS, and it encourages authorization down to the individual field in a response. That level of control minimizes the chance that a stolen token or misconfigured service will leak sensitive data.

4. Visibility and governance: One of the first NIST controls is to keep an up‑to‑date inventory and specification for every API. Knowing what you have prevents untracked “shadow APIs” from becoming liabilities and supports regulatory obligations to trace the flow of sensitive information.

5. Concrete risk reduction: Practical measures such as schema validation, rate limiting and throttling stop common attacks like injection, data scraping and denial‑of‑service. Continuous telemetry and logging help security teams spot abuse early, while web‑application firewalls and bot detection filter malicious traffic before it hits your core systems. 

Common Regulations That Map to NIST Controls

NIST’s API security guidance is not itself a regulation, but it aligns closely with many regulatory frameworks. By mapping SP 800‑228 controls to these frameworks, organisations can use a single, well‑regarded standard to strengthen security while satisfying diverse regulatory obligations. Even though NIST’s guidance is voluntary for most private‑sector firms, adopting it demonstrates due diligence and can streamline compliance audits.

Below are examples of how adopting SP 800‑228 controls helps organisations demonstrate compliance:

1. Data‑protection laws such as GDPR and HIPAA. NIST emphasises protecting sensitive data through policy enforcement and strong access controls. The guidelines recommend inventorying all APIs, restricting exposure of sensitive fields and implementing fine‑grained authorization. These measures directly support GDPR’s requirements for data minimisation and access control, as well as HIPAA’s mandates for safeguarding protected health information.

2. ISO 27001 and SOC 2. SP 800‑228 is a risk‑based framework that covers asset management (through API inventories), identity and access management (through strong authentication and authorization) and continuous monitoring. NIST notes that organisations certified under ISO 27001 or SOC 2 can use its API controls, such as authentication, monitoring and data‑leak prevention, to satisfy many of the security, confidentiality and integrity criteria these standards require.

3. US federal requirements (FISMA, FedRAMP). NIST explains that federal agencies are expected to follow SP 800‑series guidance, and many of the API controls map to existing SP 800‑53 controls. For example, maintaining an API inventory maps to asset management controls, and enforcing authentication maps to identity and access management. While SP 800‑228 is not yet mandated, agencies may adopt it to meet Federal Information Security Management Act (FISMA) obligations and FedRAMP security baselines.

4. Industry‑specific regulations like PCI‑DSS and PSD2. NIST’s recommendations for strong authentication (OAuth, mutual TLS), token management and role‑based access control support payment‑card standards that require secure authentication and limit data exposure. European open‑banking regulations (PSD2) similarly expect robust API security for financial data; implementing NIST’s inventory, access controls and monitoring helps meet those expectations.

NIST Security Framework for APIs

NIST SP 800‑228 maps API controls to the functions of the NIST Cybersecurity Framework, viz. Identify, Protect, Detect and Respond and distinguishes between baseline safeguards and sophisticated defences.

1. Baseline safeguards (Identify & Protect). The guidance starts with visibility and essential protections. Organisations should keep an up‑to‑date inventory for every API, including the owner, schema and security requirements, to prevent untracked “shadow APIs.” Runtime, all API traffic should be encrypted, all callers authenticated, and simple rate‑limiting and input filtering applied using a basic web‑application firewall. These measures block unauthenticated access, trivial denial‑of‑service attempts and common injection attacks with minimal performance impact.

2. Advanced defences (Detect & Respond). For high‑risk APIs, NIST recommends deeper inspection and behavioural analytics. Examples include full payload inspection for JSON and XML, machine‑learning‑based anomaly detection and per‑field authorization. These controls detect misuse of legitimate functionality, data exfiltration and zero‑day exploits. NIST notes that advanced defences can introduce latency and false positives and advises applying them selectively based on risk.

             NIST makes clear that not all protections are equal. Its framework divides runtime controls into two tiers:

1. Baseline safeguards target the most common API threats. They examine connection metadata, such as IP addresses, request volume, and basic request structure, and apply straightforward rules, such as TLS encryption, authentication, simple rate limiting, and coarse input validation. These measures are lightweight and address OWASP API Top 10 risks, such as broken authentication and basic injection attacks.

2. Advanced defences go further. They inspect the full content of API calls and responses, track user and service behaviour over time and use techniques like machine‑learning anomaly detection and per‑field authorization. These tools detect sophisticated abuse patterns like subtle data exfiltration or misuse of legitimate functions that basic safeguards miss.

Below is a concise table summarising the key differences between baseline safeguards and advanced defences in NIST SP 800‑228.

Measures beyond the NIST Framework for extensive API Security

NIST SP 800‑228 establishes a solid baseline for API protection, but modern attack patterns and compliance demands often require additional safeguards. However, top executives should consider the following measures to extend their API security posture beyond the NIST framework.

1. Design‑time and pre‑runtime enhancements. Shift‑left security should begin before a single line of code is written. In addition to basic spec enforcement and schema validation, advanced pre‑runtime controls such as sensitivity tagging (labelling fields that contain personally identifiable information or payment data), permission annotations, and contract testing with synthetic users help teams enforce least‑privilege access and catch design flaws. These measures improve audit trails, ensure that APIs do not expose more data than necessary and help organisations comply with data‑protection laws.
2. Advanced runtime defences. NIST’s basic runtime controls (encryption, authentication, rate limiting and coarse validation) are essential, but sophisticated attacks can still slip through. SP 800‑228, therefore, recommends additional tools for mature programs: the ability to block individual users or tokens exhibiting malicious behaviour, dynamic data masking that strips sensitive fields based on user context, semantic monitoring that tags data fields by sensitivity and tracks their flow, and non‑signature anomaly detection powered by machine learning. These capabilities detect scraping, privilege abuse and novel exploit patterns that basic controls miss. They also enable surgical responses, such as banning a single account without disrupting service for everyone.
3. Robust deployment architecture. Effective API security is as much about where you enforce controls as it is about which controls you choose. NIST does not prescribe a single model; instead, it encourages organisations to embed enforcement in multiple layers of their architecture. For customer‑facing and third‑party APIs, a centralized API gateway provides a single point for policy enforcement, authentication, throttling and logging. For internal microservices, service meshes add identity‑aware routing, mutual TLS and fine‑grained access control. Sidecar proxies can wrap legacy services without code changes, providing traffic inspection and mediation. Egress gateways enforce outbound authentication, data‑loss prevention and API key governance when calling external services. Most enterprises adopt a hybrid of these models based on API exposure, technical maturity and risk tolerance.
4. Operational and governance practices. Beyond technical controls, executives should ensure consistent identity management across services. Credential canonicalization standardizing how user IDs and tokens are interpreted, prevents attackers from bypassing authorization checks with malformed credentials: continuous telemetry, runtime alerting and forensic logging support rapid detection and response. Integrating API security into DevSecOps pipelines enables ongoing schema validation, automated penetration testing, and policy checks during development, promoting a culture of continuous improvement. Finally, aligning NIST’s controls with other industry frameworks such as the OWASP API Security Top 10 provides broader coverage of known vulnerabilities and helps prioritise mitigation efforts.

Roadmap to Building effective NIST-driven API Security Strategy

Building a robust API security program is a multi‑stage effort. The following roadmap draws on NIST SP 800‑228 and related best practices to help executives and technical teams move from ad‑hoc protections to a mature, risk‑based strategy.

1. Catalogue your APIs and assess risk. Begin by creating a complete inventory of every API internal and external with its owner, specification and runtime details. Classify each API based on the sensitivity of the data it processes, its exposure (public or internal) and its business criticality. This step supports the “Identify” function of the NIST Cybersecurity Framework and prevents unknown “shadow APIs” from undermining your efforts.

2. Establish governance and define policies. Form a cross‑functional steering group that includes security, engineering, legal/compliance and product owners. Define clear roles for API owners, security champions and incident responders. Use the risk assessment to prioritise APIs for protection and to set policies on authentication, authorization and data handling.

3. Choose your enforcement architecture. Decide where security controls will be applied. A central API gateway simplifies policy management and observability for external APIs, but can become a bottleneck. A service mesh distributes enforcement to each microservice, providing fine‑grained control and resilience. A hybrid approach combines a central gateway for high‑level policies with service‑local proxies for field‑level validation. Consider egress gateways for outbound calls to third‑party APIs. Evaluate token‑based and certificate‑based authentication options; mTLS gives strong service‑level assurance, while OAuth tokens propagate user identity.

4. Design secure APIs from the start. Adopt an API‑first development process where every API has a formal specification (OpenAPI/gRPC) and contract testing is integrated into CI/CD. Enforce schema validation for inputs and outputs to catch malformed data and prevent injection attacks, and annotate data fields with sensitivity labels and permission requirements. Conduct threat modeling and incorporate security unit tests to uncover logic flaws early.

5. Implement baseline runtime controls. Ensure every API call is encrypted (TLS/mTLS) and authenticated using proven protocols such as OAuth 2.0, OpenID Connect or SAML. Apply fine‑grained authorization at the endpoint and field level. Enforce per‑user and global rate limits, timeouts and payload size restrictions to prevent abuse and DoS. Deploy web application firewalls, bot detection and DDoS mitigation to filter malicious traffic.

6. Add advanced protections for high‑risk APIs. For APIs handling sensitive data or exposed to untrusted clients, layer on contextual controls. Implement fine‑grained blocking to ban abusive users or tokens surgically. Use dynamic data masking to strip or obfuscate sensitive fields based on user privileges. Employ semantic data monitoring that tags data fields and tracks their flow to detect exfiltration. Incorporate AI/ML‑based anomaly detection to identify unusual request patterns and emerging attacks. These controls should be applied selectively, based on risk and performance considerations.

7. Monitor, respond and iterate. Integrate API logs with a security information and event management (SIEM) system to capture who called what API, from where and whether the call succeeded. Track enforcement events (blocked requests, rate‑limit violations) and performance metrics to spot early indicators of abuse. Establish incident response procedures for API‑related breaches, with defined playbooks and communication paths. Regularly conduct penetration testing, red‑team exercises and resilience drills.

8. Align with compliance and educate teams. Map NIST controls to your regulatory requirements (GDPR, PCI‑DSS, HIPAA, FISMA, etc.) to streamline audits: document policies and evidence of control implementation. Train developers in secure coding and API design, including the OWASP API Top 10 vulnerabilities, and designate security champions within each team.

9. Continuously improve. Revisit your API inventory, risk classifications and controls at regular intervals or when new APIs are introduced. Measure your program’s effectiveness using metrics such as incident rates, mean time to detect/respond and compliance audit outcomes. Update your policies and architectures as new threats, technologies and business priorities emerge. NIST encourages starting with basic protections and progressively layering advanced measures based on risk.

Key Best Practices for NIST API Security

NIST’s SP 800‑228 outlines a comprehensive set of controls, but CIOs and CISOs can focus on a handful of best practices that deliver the most significant benefit. 

Each recommendation below is tied to a specific risk and includes a practical example to illustrate its application in the real world.

1. Maintain a living API inventory and specification. Visibility is the foundation of any security program. NIST urges organisations to document every internal and external API, including its owner, endpoint definitions, and security requirements. This inventory should be kept up to date through automated discovery tools. For example, a CISO at a financial institution might discover that multiple “shadow APIs” created by different development teams are exposing the same customer database. By bringing these APIs into the inventory, the CISO can ensure consistent authentication and authorization policies and avoid duplicate attack surfaces.

2. Enforce strong authentication and fine‑grained authorization. All API clients users, services, or devices must authenticate using secure, standards‑based methods such as OAuth 2.0, OpenID Connect, or mutual TLS. After authentication, permissions should be checked at both the endpoint and field levels. A practical example is using scopes in an OAuth token to control access to specific API endpoints and then using field-level annotations to hide sensitive account balances from an unauthorised user. This prevents broken authentication and missing authorization vulnerabilities, which remain among the most common API risks.

3. Validate input and output through schemas. Many API attacks exploit weak validation. SP 800‑228 recommends strict schema enforcement for requests and responses, specifying data types, allowed ranges and formats. In practice, this means that a “date” field must follow ISO 8601 format and a “quantity” field must be a positive integer. A CISO can mandate that developers use automated schema validators in their API gateways or service meshes to reject malformed or malicious requests before they reach business logic.

4. Use rate limiting and throttling to control resource consumption. To defend against denial‑of‑service attacks and abuse, implement global and per‑user rate limits, short time windows for requests and limits on concurrent sessions and payload sizes. For instance, an e‑commerce API might allow each authenticated user to make up to 10 requests per second, while restricting anonymous requests to 1 per second. These limits slow down brute force attempts and protect backend systems from being overwhelmed.

5. Implement comprehensive telemetry and monitoring. Detection and response require insight into API behaviour. SP 800‑228 advises logging who accessed which API, the results of policy enforcement, and performance metrics. Distributed tracing in microservices helps pinpoint where failures occur. A CISO can integrate these logs into a security information and event management (SIEM) system to detect anomalies, such as an unusual surge of 401 errors that could indicate credential stuffing.

6. Deploy perimeter threat protection, such as WAFs and bot detection. NIST recommends placing web application firewalls, bot detection and DDoS mitigation in front of APIs to block known attack patterns and automated abuse. For example, a WAF can block SQL injection attempts before they reach the API server, while a bot management service can challenge suspicious clients with a CAPTCHA. These tools reduce noise and free up runtime environments to focus on legitimate requests.

7. Adopt advanced controls for sensitive or exposed APIs. For higher‑risk scenarios, SP 800‑228 proposes fine‑grained blocking of individual tokens, dynamic data masking based on user privileges, semantic data monitoring with sensitivity labels and machine‑learning‑based anomaly detection. A healthcare provider might use dynamic masking to hide patient identifiers when accessed by third‑party analytics tools and deploy AI‑driven monitoring to flag abnormal patterns that could signal data exfiltration. Although these controls require more resources and tuning, they provide deeper protection against subtle and emerging threats.

How Levo helps ensure NIST-driven API Security and beyond

Levo’s platform translates NIST SP 800‑228 into practice by providing an end‑to‑end solution that spans development and runtime. It goes beyond the framework with intelligent, adaptive defences and a feedback loop that continuously improves security.

Levo’s platform extends NIST SP 800 228 guidance by offering protection from development through runtime. It includes adaptive defenses and a feedback loop that continuously improves security.

1. Coverage from code to production. The platform supports shift left security by automatically discovering every API. It identifies APIs whether they are internal, external or partner facing as soon as they are created. Its eBPF based discovery engine builds an inventory without manual configuration and ties each API to its specification and owner. It integrates with development pipelines to provide governance, vulnerability testing and specification validation. These measures ensure that controls like schema validation and permission annotations are applied before deployment, helping organisations meet NIST’s design time recommendations and preventing insecure code from reaching production.

2. Accurate runtime protection. In production, the platform rethinks runtime blocking. Traditional WAF tools often force a choice between aggressive blocking or passive logging. Levo resolves this tradeoff by using behavioural intelligence to block real attacks with precision. It captures system behaviour and application level data flows, building baselines for each end point and flagging deviations that indicate privilege escalation or lateral movement inside east west traffic. Enforcement decisions are transparent and auditable; security teams can review what was blocked and why and adjust rules in real time. This approach addresses NIST’s call for advanced runtime controls such as anomaly detection and fine grained blocking while minimising false positives.

3. Basic and advanced protections in one platform. Out of the box, the system detects the OWASP API Top 10 issues and other common vulnerabilities. Security teams can extend coverage with simple rules in Python or YAML to codify emerging threats or business specific abuse patterns. Policies are granular and adaptable: organisations can define different enforcement actions for each end point and environment. For example, they can block a malicious call in production but log it in staging, and embed custom header validation or regulatory triggers without redeploying services. The platform also classifies APIs by the sensitivity of the data they handle and automatically applies stricter controls and real time blocking to high risk flows. It scores endpoints based on sensitivity, exposure, and observed attack patterns, applying dynamic rate limits or stepping up authentication where needed. These capabilities align with NIST’s basic and advanced controls while offering additional flexibility and risk awareness.

4. Guided remediation and continuous improvement. When the system stops a threat, it traces the incident back to the vulnerable end point or missing control and provides remediation guidance, often including a patch or configuration change. It can also convert detected attacks into new pre production tests, feeding them into the detection and monitoring engine. This feedback loop aligns with the lifecycle approach advocated by NIST by using runtime insights to strengthen design time practices.

5. Deployment flexibility and privacy preserving architecture. The protection can run at gateways or alongside each microservice as a sidecar, allowing teams to tailor policies per service without rerouting traffic or adding latency. This mirrors NIST’s guidance to push enforcement as close as possible to each service instance. All analysis and enforcement occur within the customer’s environment; only sanitized metadata and API specifications leave the network. This design reduces operational cost, protects data privacy and makes real time protection viable for regulated industries.

The way ahead: Implementing NIST-driven security & runtime protection

NIST SP 800 228 provides a comprehensive framework for securing APIs that covers the entire life cycle, from design and development through deployment, operation and retirement. Following its guidance means maintaining a living inventory of all APIs, enforcing strong authentication and granular authorization, implementing rigorous schema validation and rate limiting, and investing in comprehensive telemetry, monitoring and advanced detection to identify anomalies and respond quickly. Organisations should treat these controls as a baseline and then layer on advanced measures, such as dynamic data masking, behavioural anomaly detection and per‑field policies, to protect high‑risk APIs and meet regulatory requirements.

Moving forward, the most effective API security strategies will combine NIST‑driven practices with modern, adaptive platforms that unify development and runtime protection. This means embedding security checks into CI/CD pipelines, using automated tools to discover and document APIs as they are created, and deploying intelligent runtime protection that learns from real traffic to block attacks with precision. 

Platforms like Levo can bridge the gap between design‑time best practices and real‑time enforcement by providing automatic discovery, behavioural baselines, fine‑grained policies and guided remediation. 

Book a demo through this link to see this live in action!