Over the past few years, API-related breaches have taken center stage in the headlines: T-Mobile, Optus, Dell…the list goes on and on and shows just how much the security landscape has shifted. In the past, perimeter security was enough—you could rest easy knowing everything was protected behind a strong firewall. But the cloud has changed everything, giving threat actors tons of access points across various cloud services. Especially APIs.
Because every API is a potential open door for an attacker, security has to be baked in from the start. In this article, you’ll learn the ins and outs of secure API design. We’ll cover core API security principles, essential controls, and how to prioritize security at each stage of the API lifecycle. You’ll come away with a clear understanding of design best practices—and how tools that provide full visibility, context-aware attack mapping, and unified code-to-cloud coverage can give you more peace of mind than any firewall ever did back in the day.
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.
What is secure API design?
Secure API design is the process of building security into the foundation of your APIs via threat modeling and worst-case scenario design. In practice, this means that Wiz validates your API contracts (OpenAPI/Swagger) against actual live traffic to identify gaps and undocumented endpoints.Taking a contract-first approach ensures security requirements are explicit, enforceable, consistent and verifiable:
Explicit: Programmers can understand specifications and machines can parse them.
Enforceable: Security measures are validated during implementation and testing.
Consistent: Requirements are applied uniformly across all endpoints.
Verifiable: Each security measure is testable against the contract.
Secure API design also includes proactively addressing the OWASP Top 10 API Security Risks through binding agreements that outline requirements for authentication, authorization, input validation, rate limiting, and data access controls.
Runtime threat detection and behavioral monitoring for APIs help teams detect anomalies in authentication patterns, unusual response sizes, and spikes in 4xx/5xx error responses. And configuration management ensures your security configurations don't drift as your infrastructure evolves, continuously validating them as services scale and change. Taken together, these steps empower you to design stronger APIs, identify/remediate issues, and keep everything running in its intended state.
(Want to learn more about securing your entire dev process? Our guide to secure SDLCs is a great place to start.)
Core principles of secure API design
In this section, we’ll look at the principles that underpin secure API design and give you key best practices in API security architecture to align with them:
Zero trust architecture: Zero trust assumes a breach is inevitable and says that no request should be trusted by default, regardless of its origin. To implement this security principle, treat all API requests as suspect and verify every API call. Even if a request seems to come from an internal network, it could be a malicious actor attempting lateral movement.
Principle of least privilege: To reduce potential damage if credentials are compromised, grant your services only the permissions necessary for their function. If a user service requires admin-level access, your API needs further development.
Data minimization: Limiting the amount of data collected, processed, and transmitted reduces exposure if a breach occurs. One key best practice? Only sending usernames and profile pictures, rather than complete user data.
Fail securely: Systems should default to a secure state when errors occur, preventing information leakage that could aid attackers. When your API fails, ensure it doesn't reveal sensitive information by using a default-deny policy and by providing brief error messages.
Defense in depth: Multiple layers of security controls give you peace of mind that if one fails, others still provide protection. Implement network controls, ensure proper authentication and authorization, validate inputs, filter outputs, limit rates, and monitor activity.
Observability and auditability: To track what happens in your system for both debugging and security investigations, enable privacy-conscious structured logging with correlation IDs, minimal retention, and support for W3C Trace Context across services.
API management: Fundamentals for cloud security teams
API management is about how you actually govern and protect your cloud app's biggest attack surface—your APIs—from day one.
Leer más
Essential security controls for API design
Time to get to the heart of the matter, the actual controls that'll keep the bad guys out and your APIs running smoothly.
Authentication that works
For user-facing applications and external APIs, use OAuth 2.0 and OpenID Connect (OIDC). These protocols are widely adopted across enterprise and consumer applications, supporting single sign-on, mobile authentication, and API authorization while maintaining clear separation between authentication (proving identity) and authorization (granting access)."
If you're using JSON Web Tokens (JWTs), validate on every request: verify the signature and algorithm (reject 'none'), check expiration (exp), not-before (nbf), and issued-at (iat) claims with clock-skew tolerance, enforce expected issuer (iss) and audience (aud), and use short-lived access tokens (15 minutes or less) with PKCE-based refresh flows. Rotate signing keys regularly, cache JSON Web Key Sets (JWKs) responsibly, and never store tokens in localStorage—use httpOnly cookies or secure server-side sessions for browser clients.
Authorization enforcement
Vulnerabilities such as broken object-level authorization (BOLA) and broken function-level authorization (BFLA) occur when access to objects or functions is not correctly verified. BOLA is particularly dangerous, and it's one of the most prevalent API vulnerabilities. With BOLA, attackers can see other users’ data by simply swapping an ID in the URL. The main issue is developers include verification checks for users but don’t include checks that confirm a user has access to what they are requesting.
RBAC is a starting point for permission management, but role checks alone don't prevent BOLA (Broken Object-Level Authorization) or BFLA (Broken Function-Level Authorization). For every request, verify that the authenticated user owns or has explicit permission for the specific resource ID being accessed—not just that they have a valid role. For complex scenarios, consider ABAC (attribute-based) or ReBAC (relationship-based) access control, and enforce object-level ownership checks at the handler level before returning data.
Input validation
Always double-check information and be cautious about what you trust: SQL injection and cross site scripting (XSS) are just two of many attacks that rely on limited checks. First, verify data when it enters your system, which means checking data types, formats, lengths, ranges, and any specific attributes relevant to a particular piece of data. You’ll need to validate on the server side too, regardless of any client side validation, because attackers could bypass browser or app checks.
Output that doesn't leak secrets
Keep responses clear and relevant. Avoid sharing sequential numbers, internal IDs, stack traces, or database error messages, as this information can reveal your system information—making it priceless to attackers.
Your best bet is to think about what each client actually needs. If a mobile app displays only a username and avatar, responding with all the user’s details is an unnecessary risk. Instead, return only the minimum data required.
Rate limiting to protect your service
For tight security, build rate limits into each layer:
Per-user limits prevent one account from overwhelming your service.
Endpoint limits can reduce the impact of repeated computationally expensive processes or limit calls to sensitive data.
Adaptive rate limiting reacts to suspicious patterns including request bursts, distributed attack sources, token reuse, and anomalous endpoint access. Implement multi-dimensional throttling per authenticated identity, API key, source IP, and endpoint path. When limits are exceeded, return HTTP 429 (Too Many Requests) with a Retry-After header indicating when the client can retry, allowing well-behaved clients to back off gracefully while blocking malicious traffic.
Encryption everywhere
Prioritize these encryption best practices to protect your data:
Prefer TLS 1.3 for all connections, including internal service-to-service (east–west) traffic; where compatibility requires TLS 1.2, enforce strong cipher suites (AES-GCM, ChaCha20-Poly1305) and disable weak algorithms (RC4, 3DES, CBC-mode ciphers). Internal networks are not inherently trusted—attackers move laterally through compromised environments, making encryption mandatory even for private traffic.
Implement end-to-end encryption for sensitive data.
Avoid hardcoding keys.
Regularly rotate certificates to prevent outages caused by expirations.
Error handling for pros
As we’ve seen, error messages should help legitimate users debug without revealing infrastructure details to attackers. Use standardized error structures following RFC 7807 (Problem Details for HTTP APIs) with type, title, status, and detail fields. Keep client-facing messages generic (e.g., 'Authentication failed') while sending full diagnostic context—including request IDs, stack traces, and failure reasons—to your SIEM for security analysis. This approach prevents information leakage while maintaining operational visibility. This way, the user sees an “Authentication failed” error message, but only your logs provide details of the actual reason for failure.
Watch 12-min demo
Learn about the full power of the Wiz cloud security platform. Built to protect your cloud environment from code to runtime.
Implementing secure API design across the development lifecycle
Next, let’s look at how to integrate security into your entire development process so you can embed it in your organization's DNA.
Planning and design
Initiate API threat modeling during the design phase, not during the security review.
Utilize OpenAPI/AsyncAPI for contract-first design.
Implement data classification and minimization techniques, selecting appropriate authentication flows for each client type (SPA, mobile, backend).
Development
Integrate SAST and SCA tools into your IDE and CI pipeline.
Perform secrets scanning to identify leaked credentials.
Validate API schemas against contracts.
Unit test your authorization policies (OPA/Conftest).
Generate SBOMs to track dependencies.
Testing
Run API-focused DAST scans.
Conduct schema-guided fuzzing against live endpoints.
Negative test for BOLA/BFLA to verify users can't access others' resources or admin functions.
Deployment
To ensure consistent setups, use infrastructure as code (IaC).
Implement security measures at gateways to control user access.
Leverage tools that check configurations before deployment to ensure everything is correct.
Use methods like canary releases or feature flags for riskier changes, to allow easy reversion if a security update causes issues.
Operations
Monitor discrepancies between specifications and live traffic, and implement automated alerts with incident response runbooks.
Enforce API versioning, deprecation policies, and regular key/token rotation.
Keep track of security goals, such as how quickly you spot and respond to issues.
Integrate policy-as-code checks and contract validations into your CI/CD pipeline, auto-assign fixes to code owners, and trace cloud API issues back to the source repository for root-cause remediation.
Secure API design in cloud-native environments
While cloud-native architectures offer incredible scalability and flexibility, they also introduce security challenges that can make your APIs a target. Here’s what’s at stake—and what to do about it.
Container networking
Your APIs might become accessible to the wrong people if network settings aren't configured correctly, which can happen due to default allow policies in service meshes, misconfigured ingress controllers, or complex Kubernetes networking systems.
Consider this scenario: A developer deploys a new microservice and forgets to set network policies. Now, by default, that service can talk to every other service in the cluster, including payment processing, user authentication, and customer data stores. If the service is compromised, the attacker could reach and compromise these other services.
Service-to-service communication
Service-to-service communication requires distinct security measures because machines talking to machines create different threats than browser-based users. For external clients accessing the system (north–south traffic), use security gateways that terminate TLS and check API keys or OAuth tokens.
For internal communication between services (east–west traffic), implement TLS where both sides verify each other's identity. This includes using certificates and specific rules to ensure there’s secure, directed communication between services. Without these measures, an attacker in one service can impersonate others and move through your infrastructure.
Kubernetes admission controllers
Using a policy-based admission controller, such as Kyverno or OPA Gatekeeper, ensures your API deployment is validated against a predefined policy. These policy engines verify that software comes from approved sources and interactions with other systems are limited. Policies can also block deprecated APIs, require vulnerability scans, and ensure proper labels.
Here’s an example: Without an admission controller, a developer could deploy an API service running as root with access to inappropriate services and no resource limits. With an admission controller, the deployment would be automatically rejected, with the policy violations listed as the reason for the rejection.
Serverless security
The big three cloud providers all have their own serverless functionality that’s designed so you manage software and not servers. That said, you still have to manage security: Functions are easy to spin up, but each can be a potential entry point and wind up with too many permissions or respond to event sources they shouldn't.
To solve these issues, implement least-privilege IAM roles per function, set execution timeouts, and use strict event-source allowlists to reduce attack surfaces. Also be sure to enforce payload size limits and input validation at the edge with API gateway models, ensuring functions process only validated requests from authorized sources within defined resource boundaries.
Dynamic infrastructure
The dynamic nature of the cloud means your security controls need to adapt just as fast as your infrastructure. Auto-scaling and spot instances can continuously deploy and terminate instances as demand, availability, and costs change. Containers can be deployed in just seconds and are automatically upgraded whenever new versions are available.
Configuring security manually simply doesn’t work in this environment—and even IaC may not provide the required security as infrastructure changes. Security policies attached at resource creation can provide better protection from over-permissive roles, misconfigurations, and runtime drift.
For teams diving deep, read our guide to cloud security architecture.
Evaluating and improving your API security posture
Improving code quality is crucial, but security also requires ongoing attention. Once you’ve nailed down secure API design, here’s how to stay ahead of the rapidly changing threat landscape:
API discovery and inventory: You can't secure anything you don't know about. Shadow APIs are real, and they're usually the ones that end up in breach reports. Leverage automated discovery tools, runtime API detection, and regular audits to find the APIs that developers deployed "just for testing" six months ago and forgot about.
API risk assessment: Not all vulnerabilities are created equal. An API handling credit card data requires more attention than one that returns your company's office locations. That’s why you need to consider exposure level, data sensitivity, authentication strength, and business impact in your threat-modeling processes.
Prioritize and remediate risks: You can't fix everything at once, and trying to will burn out your team. Instead, triage identified vulnerabilities by exploitability and impact. Critical auth bypass on a public API? Drop everything. Minor information disclosure on an internal endpoint? Schedule it. Create a remediation roadmap with realistic timelines, assign ownership, and track progress.
Educate developers on best practices: Developers aren't trying to write insecure code; many times, they just don't realize what "secure" looks like for APIs. Regular training on the OWASP Top 10 API Security Risks, secure coding patterns, and your organization's specific security requirements turns your dev team from your most significant risk into your most powerful defense.
How Wiz helps you evaluate and improve API security posture
If you’ve read this far, one thing is clear: API security isn’t something to put on the backburner. The good news? With the right tools, improving your API security posture can be easy.
Enter Wiz.
Wiz’s approach to API protection is characterized by full visibility, key context, and continuous coverage. Look to Wiz for an all-in-one, unified platform that provides:
API discovery and inventory: Wiz uncovers the APIs you overlooked, and those you didn't even know existed. Because Wiz is agentless-first, you can get started scanning in minutes. Because Wiz is agentless-first, you can get started in minutes via cloud API integrations that discover APIs through infrastructure metadata. Adding the optional lightweight eBPF-based Wiz Runtime Sensor extends discovery to runtime traffic analysis, uncovering shadow APIs and undocumented endpoints that don't appear in infrastructure configurations.
API risk assessment: Wiz is always on the hunt for API-specific security issues that traditional vulnerability scanning tools miss. On top of catching the classics from OWASP's Top 10, like broken authentication and excessive data exposure, Wiz also identifies insecure design patterns before they become exploitable. Better yet? You can make alert fatigue a thing of the past because Wiz knows the difference between a theoretical vulnerability and one that's actually dangerous in your environment.
API toxic combinations: A misconfigured API may not be a serious issue unless it’s also publicly accessible, processes personally identifiable information, and has poor authentication measures. Wiz identifies toxic combinations where multiple risk factors intersect to create genuine business risk. The Wiz Security Graph maps relationships between cloud resources—showing how an internet-exposed API connects to a database storing PII through specific network paths and IAM roles. This graph structure reveals complete attack paths: for example, visualizing that a publicly accessible API with broken authentication can reach a production database because the Lambda function has overly permissive IAM credentials. Teams can then break the attack path at its weakest point—fixing the authentication flaw, restricting the IAM role, or segmenting the network.
Want to see how contextual, agentless visibility can protect your APIs—and everything you build and run in the cloud—without agents to deploy or performance overhead? Schedule a personalized demo today to see how Wiz discovers shadow APIs, prioritizes real risks through the Security Graph, and traces issues from runtime back to source code.
Secure APIs from code to cloud
Book a demo to see how Wiz helps security teams uncover API risks and attack paths in real time.
