An integration can remain technically functional long after the assumptions that made it secure have changed.
Consider an API connection introduced eighteen months ago. It still authenticates successfully, requests still return valid responses and customers have reported no obvious problems. During those eighteen months, however, the provider has released a newer API version, the application has added two user roles, an integration credential has gained additional permissions and an old endpoint has remained online because one internal service still depends on it.
From an availability perspective, the integration works.
From a security perspective, it needs another look.
API security is especially prone to this kind of drift because APIs sit on boundaries: between applications, users, services and external providers. Those boundaries change as products evolve.
NIST's updated 2026 Guidelines for API Protection for Cloud-Native Systems treats API protection as a lifecycle concern covering both pre-runtime and runtime controls, rather than something completed when an endpoint first reaches production.
For Levelworks, maintaining API security sits primarily at the intersection of Secure and Integrable App Health. An application should continue exchanging data with other systems, but it should do so through integrations whose identities, permissions, endpoints and trust assumptions remain appropriate over time.
Security maintenance becomes difficult when the organisation cannot answer a basic question:
Which APIs are actually in use?
Applications tend to accumulate interfaces over time:
Documentation often describes the intended API estate rather than the real one.
That gap matters because an endpoint nobody remembers may still be exposed, authenticated with outdated credentials or running a version that no longer receives the same scrutiny as current functionality.
The OWASP API Security Top 10 identifies Improper Inventory Management as an API-specific risk, reflecting the difficulty organisations face when old hosts, API versions and undocumented endpoints remain available.
API security maintenance should therefore keep an inventory that can answer:
The objective is not perfect documentation for its own sake. It is making sure there is no security boundary whose existence has effectively been forgotten.
Authentication answers:
Who is making this request?
Authorization answers:
Should that identity be allowed to perform this operation on this resource?
It is usually the second question that becomes more complicated as an application grows.
Suppose the original application had two roles: user and administrator.
A year later it has:
An endpoint that was safe under the original two-role model may now require more granular authorization.
OWASP ranks Broken Object Level Authorization first in its 2023 API Security Top 10. The underlying issue is straightforward: being legitimately authenticated to an API endpoint does not mean a caller should have access to every object identifier submitted to that endpoint.
For example:
GET /api/invoices/78124
A logged-in customer may legitimately use the invoice endpoint.
The API must still verify that invoice 78124 belongs to an account that customer is permitted to access.
Changing:
/api/invoices/78124
to:
/api/invoices/78125
should not become a route into another customer's information.
Authorization therefore needs reassessment when:
Security maintenance should ask whether old authorization logic still represents today's business rules.
[Internal Link: “How to Maintain Authentication and Access Control in a Growing App”]
Object-level authorization is only part of the problem.
A user may legitimately access a customer object but should not be able to modify an internal account status. A support user may view account information without being entitled to invoke administrative operations.
OWASP distinguishes these risks through both Broken Object Property Level Authorization and Broken Function Level Authorization.
This becomes a maintenance concern when API schemas evolve.
Suppose an API originally returns:
{
"name": "Example Ltd",
"plan": "business"
}
Later, the underlying object gains internal fields:
{
"name": "Example Ltd",
"plan": "business",
"risk_score": 72,
"account_status": "review"
}
If the API automatically serializes the entire internal object, fields that were never designed for external exposure may suddenly become visible.
The reverse problem can occur with updates: allowing clients to submit an entire object can unintentionally give them control over fields they should never modify.
Every substantial schema change should therefore prompt a simple security question:
Has the API started exposing or accepting anything the caller should not see or control?
API credentials are often created once and then forgotten because they keep working.
That is precisely the problem.
API keys, OAuth client secrets, signing keys, certificates and service-account credentials should have:
Long-lived credentials become particularly risky when nobody knows which systems still depend on them.
A team may hesitate to rotate a five-year-old API key because it is unsure what will break.
That is a maintenance failure before it becomes a security incident.
The OWASP REST Security Cheat Sheet advises protecting API keys carefully and cautions that API keys alone should not be relied upon to protect sensitive or high-value resources. It also recommends revoking keys where appropriate rather than treating them as permanent identities.
For externally integrated applications, rotation should be designed rather than improvised.
That may mean supporting an overlap period where old and new credentials work simultaneously, updating the consumer, confirming successful use of the new credential and only then revoking the old one.
Without this capability, teams tend to postpone rotation because the operational uncertainty feels greater than the security benefit.
Using OAuth does not remove the need for ongoing security work.
OAuth guidance itself evolves as real-world attack techniques become better understood.
The IETF's current OAuth 2.0 Security Best Current Practice, RFC 9700 updates earlier OAuth security advice based on practical deployment experience, introduces mitigations for newer threats and deprecates some modes of operation now considered less secure.
That is a useful illustration of a broader point:
An authentication design that was acceptable when an integration was created may deserve reassessment later even if it still functions correctly.
Teams maintaining OAuth integrations should periodically verify things such as:
This does not mean redesigning every integration whenever a specification changes.
It means knowing enough about the implementation to determine whether newer guidance materially affects it.
Permission tends to expand more easily than it contracts.
A third-party integration may initially need read access to customer records. A new feature later requires write access, so the credential receives an additional scope. Six months later, that feature is removed.
Does the write permission disappear too?
Often, it remains.
Over time, integrations can accumulate permission they no longer require.
Review the scopes and privileges assigned to:
Ask:
If we were creating this integration today, would we grant it the same access?
If not, the access model has drifted.
Least privilege is most useful when treated as something periodically maintained rather than something declared once during architecture design.
API version changes are normally discussed as compatibility issues, but they can have security consequences too.
An older endpoint may:
Keeping an old API version alive indefinitely therefore expands the security surface.
Imagine the current application uses:
/api/v3/customers
but /api/v1/customers remains accessible because one integration never migrated.
The development team may focus security testing on v3 while v1 quietly becomes the weaker route into the same underlying data.
Deprecation should therefore have an end state.
Track which consumers still use older versions, communicate migration deadlines and eventually remove endpoints whose continued availability no longer has a justified business need.
[Internal Link: “Why Third-Party Integrations Fail Over Time”]
Applications frequently treat third-party APIs as trusted because the provider is legitimate.
That trust needs boundaries.
OWASP's API Security Top 10 includes Unsafe Consumption of APIs, highlighting the risk of applying weaker validation to data received from other APIs simply because it comes from a known provider.
An external response can still be:
Security maintenance should therefore revisit how external API responses are processed when integrations or provider contracts change.
Useful controls include:
The security principle is simple:
External data remains external data, even when it comes from a vendor you trust.
API traffic often carries authentication tokens, customer information and commercially sensitive data.
Transport protection should therefore remain part of API maintenance.
The OWASP REST Security Cheat Sheet recommends HTTPS-only endpoints for secure REST services, while the current OAuth security BCP recommends end-to-end TLS between OAuth clients and resource servers.
In practice, maintenance includes watching for:
Certificate automation reduces manual work, but it should not eliminate visibility. An automatically renewed certificate is useful only if failures in the renewal process are detected before expiry.
Rate limiting is often configured using assumptions made at launch.
Those assumptions may no longer hold after traffic grows, new partners are introduced or one endpoint becomes substantially more expensive to process.
Rate limits help protect both availability and security because unrestricted API consumption can create resource exhaustion or support automated abuse.
The OWASP REST Security Cheat Sheet recommends returning 429 Too Many Requests when clients exceed intended request rates and notes that API keys can also be used as part of usage-control mechanisms.
NIST's updated API-security guidance similarly addresses runtime controls for protecting cloud-native APIs, reflecting the fact that API security depends not only on design-time decisions but also on controls operating while the API is in use.
Do not simply make rate limits progressively higher whenever customers encounter them.
Investigate whether the traffic represents:
The correct limit should protect the system without blocking normal intended behaviour.
An API returning HTTP 200 is not necessarily behaving securely.
Security-relevant monitoring can include:
The objective is not to alert on every failed request.
Normal applications generate failed requests routinely.
Look for patterns that meaningfully depart from expected use.
This strengthens the connection between Secure and Observable App Health: security controls are more useful when the team can see evidence that they are being tested, misused or bypassed.
A deeper discussion of operational monitoring for integrations belongs elsewhere.
[Internal Link: “How to Monitor the Health of Your App’s APIs and Integrations”]
API regression testing often concentrates on functionality:
Does the endpoint still return the right information?
Security maintenance needs another question:
Does it still refuse the wrong request?
For an endpoint such as:
GET /api/projects/{projectId}
tests should not only confirm that an authorized user can retrieve a project. They should also verify that:
Negative tests are particularly valuable for APIs because many authorization failures occur when legitimate requests are modified slightly rather than when obviously malicious input is supplied.
The OWASP API Security Top 10 repeatedly emphasizes object-, property- and function-level authorization precisely because API endpoints frequently expose predictable resources and operations.
Those controls should therefore be regression-tested when related API behaviour changes.
A yearly security assessment may still be useful, but API changes can make part of that assessment stale quickly.
Consider triggering a focused security review when:
NIST SP 800-228's lifecycle-oriented approach is useful here because it considers API risks and protection measures across both development and runtime rather than treating deployment as the end of API security work.
The depth of reassessment should match the change.
A new optional response field does not necessarily require a complete penetration test. Replacing the application's identity architecture probably deserves more scrutiny.
Integrations are unusually vulnerable to ownership gaps.
Your team may own one API while another organisation owns the other. Internally, one group may maintain the business workflow while another manages credentials or infrastructure.
Security responsibilities need explicit ownership.
For each important integration, someone should know:
If the answer to each question is “someone on the platform team,” the integration is not well owned.
This matters especially when employees leave or responsibilities move between teams. Credentials, vendor accounts and webhook secrets should not depend permanently on the person who originally created them.
Periodically take each important integration and work through a short review:
Area
Maintenance question
Inventory
Do we know every active endpoint and API version?
Ownership
Is there a clear technical and security owner?
Authentication
Is the current mechanism still appropriate and supported?
Authorization
Do roles and object permissions still match current business rules?
Credentials
Are keys, secrets, tokens and certificates properly stored and rotatable?
Scopes
Does the integration have more permission than it currently needs?
Schema
Are we exposing or accepting new fields that change security assumptions?
Versions
Are deprecated endpoints still reachable unnecessarily?
External data
Do we validate responses instead of trusting providers implicitly?
Abuse controls
Are rate limits and usage controls appropriate for current traffic?
Monitoring
Would suspicious API behaviour be visible?
Testing
Do security regression tests verify denied as well as allowed operations?
A review like this is far more useful than asking only whether the API is “up.”
Availability says the integration can communicate.
Security maintenance asks whether it is still communicating under the right trust conditions.
APIs are agreements between systems, but those systems do not remain still.
Roles change. Data models expand. Credentials age. Providers revise authentication guidance. Old API versions linger, integrations receive broader permissions and entirely new workflows appear behind endpoints that originally served a much simpler application.
Keeping integrations secure therefore requires more than protecting an endpoint once.
It means maintaining an accurate API inventory, revalidating authorization as the product changes, managing credentials throughout their lifecycle, reducing unnecessary scopes, retiring obsolete versions, validating third-party data, monitoring suspicious usage and retesting security controls whenever the integration materially changes.
For Levelworks, that is the relationship between Secure and Integrable App Health.
An integration is not healthy merely because requests still succeed.
It should remain understandable, supportable and appropriately trusted even as both sides of the connection evolve.
