Top API risks and how to mitigate them

API publishing risks

Let's examine some API vulnerabilities and risks, starting with those based on API publication, and security measures that can help mitigate them.

Bad or weak authentication

To be at all safe to use, even internally, APIs should use authentication mechanisms to ensure the entity asking them to do something is what it says it is and it's connected to whatever people or institution it says it is.

Unfortunately, during API development, coders all too often fail to implement current and strong authentication. Consequently, like other web applications, API back ends are often riddled with weak authentication that malicious hackers can easily compromise or broken authentication they can bypass.

When the API can't correctly establish the identity of the entity at the other end of the API call, the enterprise is at risk of performing actions, sharing sensitive information or accepting input from people or systems it does not mean to.

Mitigation

Follow secure development methodologies. Coders should standardize on strong authentication modules and use automated testing during development cycles that reject any code with nonstandard authentication.

The cybersecurity team should also conduct penetration testing against APIs, looking for inadequate authentication.

Knowing where API requests come from is only half the battle. The other half is correctly controlling access to back-end systems and data based on that identity.

Bad authorization

Knowing where API requests come from is only half the battle. The other half is correctly controlling access to back-end systems and data based on that identity. Here, problems center around access rights -- either they are inadequate or overly generous.

Inadequate API access might prevent unauthorized access but leaves legitimate partners or customers without authorization to retrieve data and services they need to function appropriately.

At the other end of the spectrum, overly broad access control lets users see or do things beyond what they need to and could allow malicious actors to gain access to private information and systems.

Mitigation

Full user acceptance testing -- automated if possible -- should replicate real-world access scenarios.

The goal is to assess the API's ability to grant a properly authenticated request access to all the necessary data, from whichever objects or data stores control it. Such security testing should also include requests to retrieve data or perform actions for which the test accounts are not authorized. This is to ensure they fail in the expected ways.

Enterprises that publish APIs should add API reviews to their overall authentication policy audits. And they should test for compliance with those policies as part of their regular penetration testing.

Denial-of-service attacks

As network-facing services, APIs can be subject to DoS and DDoS attacks designed to swamp them with bogus traffic. If the APIs provide business-necessary services, their underperformance or lack of availability could have serious consequences for the business.

DoS or DDoS attacks could mean APIs are unable to service legitimate requests in a timely manner. Or malformed requests could cause them to consume resources without releasing them, thereby exhausting them. Lastly, they may simply be pushed to the point where the API process crashes.

Mitigation

Queue and throttle requests before they get to back-end systems. Also, consider implementing DDoS defenses and tighter coding to prevent "hanging request" problems.

Server-side request forgery

Among top API risks is the server-side request forgery. SSRFs turn the API service into an unwitting dupe of a bad actor, thus creating the risk of a lateral compromise or of becoming an accomplice to attacks on others.

By submitting a carefully constructed request via the API, the bad actor seeks to get the API service to reach out to some other system inside the infrastructure or some third-party resource or site. For example, an API call expecting to be fed a URL for a person's LinkedIn page might instead be fed a request to open a TCP port on the API service's own host.

Mitigation

Limit the type and scope of valid URLs on inputs so they can do only what is intended. Use a current parser on URLs to make sure they are well formed and of the expected type. Use an allowlist to control where URLs can point.

IT should also implement zero trust in the API environment to prevent services from reaching out laterally to systems with which they shouldn't communicate. Note that this is an example of a broader risk -- insufficient vetting of inputs from API requests.

Malicious inputs

API handlers can, and too often do, naively accept user input and stash it in data structures in the code or external databases without first vetting it. As with web apps, this is the classic vector for SQL injection attacks, buffer overflow attacks, SSRFs and more.

APIs face the same risk that false data or nonsense data is treated as valid. If that happens, the API handler could become the platform for some sort of lateral attack on internal targets or reflected attack on external ones.

Mitigation

Never accept raw input from the requester. Always parse and validate inputs.

Data oversharing

APIs sometimes expose more data than the company's data security policy says they should. This creates the risk that personally identifiable information or other protected information could be revealed inappropriately.

Excessive data exposure can result from building and testing APIs against an extract of a data set but turning the code loose on a broader data set in production. It can also be the result of authentication issues -- see above.

Mitigation

Test against data sets that limit the number of records but not the types or the fields contained in order to more accurately validate access. Use data loss prevention systems to monitor and alert on, block or actively redact data that should not be revealed in that way.

API dependency

When internal processes depend on the same API services as external integrations, enterprise business processes are exposed to interference by API users. API-focused DoS attacks can cripple internal processes -- not just externally facing ones -- and seriously hamper the organization's ability to do business.

Mitigation

Segregate inside-facing API services from outside-facing ones to keep attacks on external APIs from directly affecting internal ones.

Additional API risk sources

Other common risk sources for companies publishing APIs include the following:

• Inadequate version control of the services underlying the APIs, leading to mismatches in authentication, authorization and input scanning.
• Missing or inadequate logging of API activity and monitoring of the logs.

API consumption risks

API risks are not limited to publication; consider the following risks related to API consumption.

Unsafe consumption of data

When an organization uses APIs to retrieve data from systems elsewhere, it creates the risk of that data being bad and even malicious. It might lead to the organization making bad decisions and taking incorrect actions or reporting falsehoods instead of facts to regulators, customers or partners.

Mitigation

Input validation is key in securing APIs. Keep track of where data comes from so that problems can be properly attributed and investigated.

Undocumented third-party risk

Enterprises open themselves up to problems when they take on third-party risk -- in essence, risks stemming from their suppliers' suppliers.

So many APIs consume other third-party APIs -- which may consume other APIs still and so on -- that it can be difficult to know how many different entities might ultimately be involved in serving up the response to an API request. This can result in a vast attack surface.

Mitigation

Control your API ecosystem by limiting the number of other APIs your own APIs use. Seek contractual agreements with those other API providers to define and limit your third-party risk.

Undocumented risk to business processes

When business processes depend on API consumption but that dependency is not documented, it is all too easy for the process to break.

Changes to the business process might be made in ignorance of the fact they require changes to how the API is used -- for example, resulting in the process functioning incorrectly. Or changes to how the API works may result in subtle changes to its behavior that are problematic but not immediately apparent.

Mitigation

Thoroughly document all business processes. Use zero-trust architectures to restrict internal systems from reaching out to either internal or external APIs without explicit permission to do so.

The risks inherent in APIs are not unique to APIs. To manage top API risks and ensure the organization's network remains secure, IT and cybersecurity systems must be familiar with the types of problems creating the risks, as well as the tools and strategies designed to mitigate those hazards.

John Burke is CTO and principal research analyst with Nemertes Research. With nearly two decades of technology experience, he has worked at all levels of IT, including end-user support specialist, programmer, system administrator, database specialist, network administrator, network architect and systems architect. His focus areas include AI, cloud, networking, infrastructure, automation and cybersecurity.