Understanding API security standards
API security standards are the formal specifications, protocols, and frameworks you apply across the API lifecycle to ensure strong API endpoint security.
It’s crucial to put these protections in place: If API security is weak, attackers can exploit API security vulnerabilities, abuse login mechanisms, access unauthorized data, or inject malicious input. Even simple misconfigurations can have huge consequences—because APIs are the connection points between software, security issues can spread rapidly across all your apps. Following REST API security best practices helps minimize these risks and maintain consistent protection across your systems.
Advanced API Security Best Practices [Cheat Sheet]
Download the Wiz API Security Best Practices Cheat Sheet and fortify your API infrastructure with proven, advanced techniques tailored for secure, high-performance API management.
Core API security standards and protocols
OAuth 2.0 and OAuth 2.1
OAuth 2.0 and 2.1 provide delegated authorization so a client can access a resource on a user’s behalf without handling passwords. To protect APIs, OAuth relies on access tokens with defined scopes and supports refresh tokens for continuity.
JSON Web Tokens (JWTs)
JWTs are an industry-standard mechanism that use verifiable and signed tokens to transmit data between two APIs in a stateless manner. JWTs solve the problem of session cookies by carrying necessary user information within the token itself.
OpenID Connect (OIDC)
OIDC adds standardized authentication to OAuth, defining how clients obtain and validate an ID token that represents the user. OIDC supports single sign-on (SSO), federation with identity providers, and retrieval of profile attributes via the UserInfo endpoint, enabling APIs to securely authenticate users and access their verified identity information without managing credentials directly.
Security Assertion Markup Language (SAML)
SAML is a standard for single sign-on between an identity provider (IdP) and a service provider (SP). It passes signed XML “assertions” that say who the user is and that they’ve been authenticated. While SAML is older and browser-centric, it still matters for APIs in many enterprises: An API gateway can accept a SAML login, then translate it to OAuth/OIDC or JWTs for the API.
Mutual TLS (mTLS)
mTLS authenticates both ends of a connection using X.509 certificates, creating strong, transport-bound trust. It’s ideal for service-to-service APIs, partner integrations, and regulated workloads requiring caller identity at the TLS layer.
Financial-grade API (FAPI) 1.0
FAPI defines hardened profiles on top of OAuth and OIDC for high-stakes financial environments like banking apps. The big takeaways? FAPI mandates stronger client authentication for maximum security, limits weak flows, and requires precise scope and consent handling.
Grant Negotiation and Authorization Protocol (GNAP)
GNAP is an emerging, flexible alternative for delegated authorization that emphasizes cryptographic key binding and privacy. To allow for richer grant negotiations and non-browser clients, it separates interactions between client and authorization servers, enabling APIs to manage delegated access with stronger security and flexibility.
OWASP API Security Top 10
The OWASP Top 10 API Security Risks list catalogs the most critical API-specific risks (e.g., broken object-level authorization, unrestricted resource consumption, server-side request forgery). Use it alongside the OWASP API Security Checklist as a threat modeling guide to identify vulnerabilities and prioritize mitigations during design and testing.
What is API compliance? A cloud security perspective
To achieve a strong API compliance posture in the cloud, you need code-to-cloud coverage. In other words, you need to build API compliance into your CI/CD pipelines, IaC, and runtime environments.
En savoir plus
API security testing standards (OpenAPI/Swagger, Postman Collections)
API security testing standards define structured approaches and tools to ensure APIs are robust and protected against vulnerabilities. API specifications like OpenAPI/Swagger and Postman Collections provide a consistent way to describe, document, and test APIs for security issues. They help validate inputs and outputs, enforce authentication, and detect issues such as injection or parsing flaws early in development. Maintaining a single, versioned API specification enables automated testing, consistent documentation, and prevents security drift across environments.
NIST SP 800-228
NIST SP 800-228 consolidates best practices for API authentication, encryption, key management, and secure design. The reference architecture and control guidance it offers are applicable to both federal and enterprise contexts.
Other NIST guidance relevant to API security includes:
NIST SP 800-218 (Secure Software Development Framework): Defines practices for secure API design, development, and deployment across the SDLC
NIST SP 800-207 (Zero Trust Architecture): Establishes principles for continuous authentication and authorization of API calls without implicit trust
NIST SP 800-53 (Security and Privacy Controls): Maps API security controls to families, including Access Control (AC), Identification and Authentication (IA), Audit and Accountability (AU), and System and Communications Protection (SC)
ISO/IEC 27001 and ISO/IEC 27017
ISO 27001 establishes requirements for an information security management system (ISMS) and guides businesses on how to choose security controls based on identified risks; ISO 27017 extends guidance to cloud services. Apply them to formalize API policies, roles, supplier controls, and secure development practices.
PCI DSS for APIs
APIs that store, process, or transmit cardholder data fall under the scope of PCI DSS. Expect requirements for strong cryptography, robust authentication, network segmentation, detailed logging/monitoring, and vulnerability management.
Zero trust architecture
Zero trust is a security strategy that never assumes implicit trust based on network location—for APIs, this means every call must be authenticated, authorized, and continuously validated with strict API access control. Combined with microsegmentation, mTLS, and short-lived tokens, zero trust helps constrain threat actors’ movement and reduce the blast radius of attacks.
What 12-minute demo
Learn about the full power of the Wiz cloud security platform. Built to protect your cloud environment from code to runtime.
Watch now
How standards and compliance requirements are applied to APIs in 2026—and beyond
Now that we’ve covered the basics, let’s examine how standards and regulations are being applied to APIs right now, along with forecasts for future trends:
Regulatory compliance meets API reality (EU NIS2 & DORA)
EU cybersecurity legislation applies directly to APIs: Staying compliant with NIS2 and DORA requires you to maintain accurate and risk-appropriate API inventories (including shadow and zombie APIs), capture identity-linked logs (authenticated user or service principal, action, timestamp, resource accessed) with data minimization (hashing PII, redacting sensitive payloads), centralize monitoring across all API gateways and service meshes, and formalize coordinated vulnerability disclosure (CVD) processes and 72-hour incident reporting timelines as required by NIS2 Article 23. If you’re in scope, be prepared to show evidence—artifacts, not assertions—that these controls run in production.
Next-gen authentication: GNAP alongside OAuth
GNAP, standardized as RFC 9635, is still maturing, so many teams are considering it for experimental or future-looking platforms where OAuth’s constraints might be limiting. Early adopters will likely pilot GNAP on targeted flows while continuing broad OAuth 2.1/OIDC integration for interoperability.
Financial-grade profiles go mainstream (FAPI 2.0)
For high-stakes APIs (open banking, fintech, regulated data), FAPI 2.0 (the latest version of FAPI) is now a finalized security profile. Compared to FAPI 1.0, it tightens client authentication, and FAPI 2.0 also simplifies signed requests/responses and introduces sender-constrained tokens. Use it where fraud risk prevention, interoperability, and auditability are non-negotiable.
OWASP API Top 10
In 2026, the OWASP API Top 10 Security Risks list remains a critical resource. Treat it as your shared risk language for design reviews, testing, and monitoring—especially around object-level authorization, excessive data exposure, and inventory/version control. Best practice? Map each risk to concrete controls and show CI/CD evidence.
Qu’est-ce qu’une CNAPP ? [Plateforme de protection des applications cloud-native]
En savoir plus
Cloud-native API security challenges
Microservices and container security
In microservices, internal APIs multiply quickly, creating far more east–west traffic to secure. A service mesh helps set a consistent baseline—mTLS for identity and encryption, policy-based authorization at the proxy, and unified telemetry—so protection follows every call. For container-to-container communication, pair those mesh controls with runtime hardening to keep the blast radius small.
Discovery is another big challenge in dynamic clouds, considering endpoints appear and vanish with scaling. That means you’ll want to combine mesh inventories with ingress/egress logs and spec scanning to find shadow or orphaned APIs. Once you have complete visibility, treat API inventory and lifecycle as a product: Maintain versioned OpenAPI contracts, clear ownership, data classification, and real deprecation timelines—no contract or owner, no deployment.
To implement all these tips, pick a tool that eliminates manual work. One note of caution, though: Agent-based tooling often struggles in fast-paced environments—agents must be deployed, kept up to date, and granted elevated privileges. And even if you tick all these boxes, agent-based tools will still miss short-lived nodes as your platform scales. That’s why many organizations are adopting agentless scanning solutions that provide comprehensive API discovery and security posture management without the overhead of per-host agents.
DevSecops
DevSecOps means “shifting left” so that you find API vulnerabilities before production. To maintain development speed while shifting left, build checks into normal dev work:
Use contract testing and schema validation during API design and coding, not later.
Make sure the CI/CD pipeline is secure: Leverage branch protections and signed commits so only trusted changes get deployed.
Once it’s deployed, continuously testing code with automated tools can help uncover vulnerabilities in a dynamic environment.
Wiz: Securing APIs from development to runtime
Wiz provides deep visibility and actionable security findings from code to cloud. It automatically (and agentlessly) discovers APIs, identifies vulnerabilities and misconfigurations, and prioritizes risks based on cloud context, data sensitivity, and external exposure.
Here are just some of the ways that Wiz protects the full lifecycle of APIs:
Unified API & cloud security: Wiz unifies API security with cloud posture management and shift-left controls in a single platform, enabling a holistic view and identifying "toxic combinations."
Continuous discovery and contextual risk prioritization: Wiz continuously discovers and classifies API endpoints, identifying sensitive data and external exposure for precise prioritization of fixes.
Shift-left security & OWASP API Top 10 alignment: Wiz is actively working towards full coverage of the OWASP API Top 10, incorporating OpenAPI schemas and integrating security earlier in the development lifecycle.
Ready to learn more? Get a demo of Wiz and see how unified visibility plus contextual remediation transforms API security.
Secure APIs from code to cloud
Learn how Wiz Code scans IaC, containers, and pipelines to stop misconfigurations and vulnerabilities before they hit your cloud.
