API Integration Security Review Checklist

APIs carry over 70% of web traffic now, which means they carry most of the data too. Wherever data moves, attackers show up eventually, and the numbers back that up: Akamai's 2026 State of the Internet report found 87% of organizations had an API-related security incident in 2025, with average daily attacks per org jumping from 121 to 258, a 113% year-over-year increase. Salt Security's Q1 2025 data puts it even more bluntly: 99% of organizations ran into an API security problem in the past year, 34% of which involved sensitive data exposure or a privacy incident. More than half (55%) slowed down a product launch because of API security worries, so this isn't just a security cost anymore, it's a speed cost.

Here's the part that should keep people up at night: only 21% of organizations say they can reliably detect attacks happening at the API layer, according to Traceable and the Ponemon Institute's 2025 survey of 1,548 respondents. Organizations run an average of 131 third-party APIs, and only 13% can stop more than half of the attacks aimed at them. Scale that up: the average org now has around 3,000 APIs touching sensitive data, and 12% of those have a known weakness sitting in them already. IBM's Cost of a Data Breach report, covering March 2025 through February 2026, priced the average breach at $6 million, up 35% from $4.44 million the year before. In the US, that number hit a record $10.22 million.

None of this means you need to fix everything at once. It means you need to figure out which controls belong at which point in an integration's life and build a repeatable process around that.

Why lifecycle staging makes checklists repeatable

A flat checklist gets read once at launch, then forgotten. A staged checklist works differently because different problems surface at different moments, and no single review catches all of them.

Three stages matter here. Pre-integration is where design and vendor decisions get made. It's also where the worst mistakes happen, because they're the hardest to walk back later. Pick the wrong authentication model, hand out oversized permissions, or skip the inventory step, and you're stuck retrofitting security onto something already running in production. Implementation is the build-and-test window, when authorization gaps and misconfigurations get baked in and are still cheap to catch. Post-go-live is ongoing operations, and it's the stage most teams treat as optional, even though 95% of API attacks in 2025 came through authenticated sessions, meaning the attacker already had valid credentials and spent their time probing for what those credentials could reach.

The OWASP API Security Top 10 (2023 edition) maps onto these three stages cleanly. Inventory failures (API9, Improper Inventory Management) belong to pre-integration. Authorization gaps (API1, Broken Object Level Authorization, and API5, Broken Function Level Authorization) show up during implementation. Misconfiguration (API8) and resource consumption (API4) are things you manage in ongoing operations. Wallarm's Q3 2025 data found 1,602 API-related vulnerabilities in a single quarter, with an average CVSS severity score of 7.4, solidly in High-to-Critical territory. Skip a stage, and that's where the damage tends to land.

Build your API inventory before connecting anything

None of the later checklist items mean anything if you're applying them to an endpoint nobody knows exists. Before you do anything else, build your API inventory. Authorization rules, rate limits, and patch schedules are ineffective if the API itself is invisible to your team.

The usual suspects here are shadow APIs and zombie APIs. Shadow APIs are the ones a developer spun up without a ticket, review, or inventory entry. Zombie APIs are the ones that were supposed to be retired years ago but still respond to requests. Both live outside your CI/CD pipeline and outside your standard security checks. A deprecated endpoint still wired into backend logic carries none of the controls applied to newer surfaces, because as far as anyone's records show, it isn't supposed to be there anymore.

Building the inventory takes a few concrete steps:

• Search your repositories for OpenAPI files, route declarations, SDKs, and any credentials hardcoded into integration code

• Use runtime capture via sidecars or eBPF-based observation tools to catch service-to-service traffic that static code scanning misses entirely

• For every endpoint you find, get a named owner: which team runs it, what data it touches, its lifecycle status, and a planned retirement date

• Anything without a confirmed owner gets flagged as unreviewed and treated as untrusted until someone claims it

The inventory needs to stay current as things change. When evaluating a third-party API before connecting to it, ask the vendor directly whether they maintain their own inventory and publish a deprecation policy. If the answer is unclear, that tells you something important about the vendor's security posture.

Choose your auth model before writing code

Missing Authentication was the single most common API vulnerability of 2025, responsible for 17% of all API incidents. That category covers APIs with no authentication at all guarding sensitive operations.

Pick your authentication model before a single line of build code gets written. OAuth 2.0 is the standard for token-based authentication and the right default for anything involving a third party. OpenID Connect layers identity on top of OAuth and fits user-facing applications well. JWTs (JSON Web Tokens) work well for microservices, but they need real hardening. Restrict which signing algorithms are allowed, validate the signature and key selection properly, check issuer and audience claims, enforce expiration times, and follow the guidance in RFC 8725. API keys are appropriate only for internal or low-risk APIs, and even then they need to travel over HTTPS exclusively and rotate on a set schedule.

Credential handling requires its own controls. Use short-lived access tokens with refresh tokens instead of long-lived credentials. Never store tokens in browser local storage, and never embed credentials directly in code where they might end up in a public repository. Define your rotation schedule and revocation process before go-live, not after an incident forces the question.

A compromised API key with no scoped permissions, no rotation schedule, and no anomaly detection can give attackers sustained reach into sensitive operations. Authentication answers whether a caller is who they say they are. Authorization answers whether they can do what they're attempting.

Enforce authorization at every layer, not just endpoints

Broken Object Level Authorization (BOLA) has held the top spot on the OWASP API Top 10 since the 2023 list came out. Combined with Broken Function Level Authorization (API5), these authorization failures made up roughly 28% of all vulnerabilities Wallarm identified in Q3 2025. Across the full authentication, authorization, and access control surface, the share rises to 33%.

There are two distinct failure modes here, and teams need to test for them separately because one will not catch the other. Vertical privilege escalation is a regular user calling an admin-only endpoint, such as DELETE /api/v1/users/{id}, which is a role-level failure. Horizontal privilege escalation is a user with normal permissions accessing another user's data at the same permission tier. For example, your system might allow a user to retrieve order 8821 when their session belongs to order 8820. Standard role checks do not catch this because the user technically has permission to view orders, just not that specific order.

Authorization checks need to happen at both the endpoint level and the object level, because passing an endpoint check alone says nothing about whether the caller should see a specific piece of data. Choose Role-Based Access Control (RBAC) or Attribute-Based Access Control (ABAC) based on whether access decisions hinge on contextual attributes (ABAC) or fit neatly into predefined roles (RBAC). OAuth scopes should be granular, requesting only what the integration actually needs, and the API should reject tokens carrying more permission than the request requires. Both escalation types need explicit tests written before an endpoint merges, since that is the cheapest point in the lifecycle to catch the problem.

Catch misconfigurations in the build phase

Security Misconfiguration (API8) topped Wallarm's Q3 2025 vulnerability list with 605 cases, up 33% from the previous quarter. On the broader OWASP Top 10 for Web Applications (2025 edition), Security Misconfiguration appears as A05:2025, showing up in 3.00% of tested applications across 16 different CWE categories.

Enforce TLS on all API traffic: no plaintext, no self-signed certificates in production, no TLS 1.0 or 1.1. Turn off debug endpoints, verbose error messages, and stack traces before anything ships. The 2025 OWASP Web Top 10 introduced A10:2025, Mishandling of Exceptional Conditions, covering 24 CWEs tied to bad error handling and logic that fails open instead of closed. Test specifically for APIs leaking sensitive data inside error responses.

Remove default credentials and disable any HTTP method an endpoint does not actually need. Set Cross-Origin Resource Sharing (CORS) policies explicitly, because a wildcard origin is a configuration hole, not a shortcut. Validate Content-Type headers on every request and reject anything unexpected rather than processing it silently. Run a configuration diff against a known-good baseline as part of every deployment. Without that baseline, a misconfiguration introduced by a routine deployment looks identical to one that has been present since launch.

Rate limit inputs and validate everything post-launch

Unrestricted Resource Consumption (API4) does not show up in code review. No static scan flags a rate limit set too high, or missing entirely, until real traffic or a deliberate load test exposes the gap.

Rate limiting needs to apply per consumer, meaning per API key, per OAuth token, and per IP address, not just as one global ceiling. Set limits across three dimensions: requests per second, payload size, and total response data volume. When limits are hit, return a proper 429 response with a Retry-After header rather than dropping the request silently. For high-volume legitimate users, graduated throttling with a warning before the hard block is more effective than an abrupt cutoff.

Input validation runs on a parallel track. Check every input against an explicit schema. Reject anything that does not match outright, do not sanitize it and pass it through. Validation must happen server-side regardless of what the client already checked. Database queries need to be parameterized always, never constructed by concatenating raw input into a query string. Any URL or file path your API accepts as input needs validation and sanitization. This is the attack vector Server-Side Request Forgery (SSRF, API7) exploits, where an attacker tricks your server into making requests to unintended destinations.

Unsafe Consumption of APIs (API10) is frequently overlooked. When your API calls out to a third-party API, apply the same scrutiny to what comes back that you apply to inbound requests. A compromised upstream service can return malicious content just as a malicious user can, and it will look equally clean coming through the pipe.

Monitor for anomalies across authenticated sessions

That 95% figure is worth repeating: 95% of 2025's API attacks came from authenticated sessions, meaning the attacker already had valid credentials. Detection at this stage is the primary control between an attacker and real damage.

Only 21% of organizations report a high ability to detect attacks at the API layer, according to the Traceable and Ponemon Institute 2025 survey. Most organizations are operating with limited visibility at the stage where the worst outcomes occur.

Logging needs to cover the basics consistently: timestamp, consumer identity, endpoint called, response code, and payload size for every API call. Avoid logging payload contents unless there is a specific reason to do so and the logs are protected accordingly. Centralize logs across services. Siloed per-service logs make lateral movement across your systems essentially invisible. Decide on a retention period before an incident forces the question.

Build a baseline of normal traffic per consumer and per endpoint, then alert on meaningful deviations. A pattern of repeated 403 and 401 responses from one consumer is a signal that someone is probing for access. Watch access patterns closely on any endpoint holding sensitive data, especially after a credential rotation or a permission change. Those are moments attackers specifically look for.

Schedule regular re-runs of the full lifecycle checklist. New endpoints appear. Old permissions outlast their usefulness. The system you secured six months ago is not quite the same system running today.