API Security: Navigating the Threat Landscape

An Application Programming Interface (API) is an essential and ubiquitous software that allows the exchange of information between day-to-day applications and processes, such as Software as a Service (SaaS) applications, Internet of Things (IoT) devices, universal profile login pages, and autonomous vehicles. APIs synchronize and maintain the data exchange between clients and servers, responding to each request.

Since API functionality is essential for modern-day processes, they are an appealing target for threat actors. API security can be compromised by various threats, and the impact can be very harmful to businesses and their activities.

API attacks

API attacks follow similar tactics as standard web-based attacks, including:

• Man-In-The-Middle / Session high-jacking / Identity theft – In this attack, the threat actor discreetly alters, relays, and intercepts the communication occurring between the API server and API client through packet capture technology.
• SSL Protocol Downgrade – Botnets or rogue API clients will attempt to exploit legacy vulnerabilities that haven`t yet been remediated on the client or server.
• API clients that are authenticated but not authorized – This is an instance where a user with valid credentials manipulates the API request to gain unauthorized access to another user’s information. This can lead to attempted transactions or data breaches.
• Credential leaks on mobile APIs – Mobile apps that request OAuth tokens using shared secrets can be susceptible to credential leaks, particularly if the application ID and the secret are stored in plaintext within the client application code.
• Malicious code / SQL injections – Even authenticated API consumers can pose a threat, as API calls that contain escape characters and SQL queries could potentially expose data to risks and vulnerabilities.

API security vulnerabilities

The Open Web Application Security Project (OWASP) highlights the top 10 security vulnerabilities affected by APIs, along with mitigation strategies:

1. Broken object-level authorization – APIs enable access to objects, and when the authorization is breached, attacks can be executed on a broad level. This vulnerability can be mitigated by implementing object-level authorization checks, requiring authorization credentials and access tokens to allow access.
2. Broken user authentication – Poorly implemented authentication mechanisms allow threat actors to compromise authentication tokens and exploit implementation flaws to assume the identity of authorized users. This can be solved by ensuring only trusted users are authenticated and implementing access token validations.
3. Excessive data exposure – Generic APIs expose object properties without itemized restrictions. This is done under the assumption that the client filters unnecessary data. Therefore, the threat actor is able to access Personally Identifiable Information (PII) from it. This risk can be reduced by granting data access to only trusted parties, identifying the eligibility of access, and limiting the parts of data on a need-to-know basis.
4. Lack of resources and rate limiting – APIs that don`t have restrictions for the number of resources that a client requests are vulnerable to Denial of Service (DoS) attacks and brute force attacks. These will adversely impact the performance of the API server. Actions such as enforcing rate limitations and using an API gateway will defend against this vulnerability.
5. Broken function level authorization – An authorization flaw can be created by improper access control policies. When administrative and non-administrative roles aren`t properly separated, threat actors can gain access to administrative resources and functions. Enforce strict role-based access controls, implement zero trust policies, and conduct regular security assessments and penetration tests to avoid this vulnerability.
6. Mass assignment – This vulnerability allows user-provided data to be used on an object without verifying the right to do so. This enables the threat actor to bypass security mechanisms and access sensitive data. Strong access controls can defend against this vulnerability.
7. Security misconfiguration – Insecure default configurations and incomplete and ad-hoc configurations can expose system details and sensitive user information. The solution is not relying on default configurations and not inserting sensitive information in error messages.
8. Injection – APIs are vulnerable to injection vulnerabilities such as SQL injection, NOSQL injection, and command injection. This vulnerability allows the threat actor to execute malicious commands through an interpreter. Using an API gateway, not accepting SQL and untrusted data types, and monitoring API requests provide defenses against this vulnerability.
9. Improper assets management – Poor management and documentation of API endpoints and continuing outdated API versions pose a vulnerability for threat actors to compromise and exploit information flows of applications. As solutions, keep an up-to-date inventory of all API hosts, retire or fix old API versions and implement API firewalls.
10. Insufficient logging and monitoring – Poor API security audits and inadequate API management provide threat actors with more time to breach more vulnerabilities and persistently remain active within the system. To prevent this vulnerability ensure to authenticate access to logs, automate monitoring and access to log events, and maintain an integrated and visualized platform for log management and monitoring.

It should be noted that the mitigation strategies listed above are preliminary, and once achieved, an organization should aim to implement the OWASP preventative strategies, which go much deeper.

Shadow APIs

Shadow APIs are third-party APIs developed and used without proper oversight by an organization. They can create vulnerabilities when allowed to freely inhabit an organization’s software environment. These APIs are often undocumented, untracked, and remain unnoticed, posing a significant risk to the security and functionality of software systems.

Shadow APIs impose risks such as reliability issues, increases in operational costs, non-compliance with business standards and regulations, and other risks that would cause security incidents.

To identify shadow APIs –

• Monitor every outgoing API call through API proxies—these outbound proxies log API requests and responses. Unusually slow response times and sudden spikes in resource allocations may indicate a shadow API`s presence.
• Perform log review and analysis using tools for enhanced visibility on API usage. Register logs at regular intervals and look for suspicious API activity.
• Use live monitoring tools to monitor API calls as they occur and their performance.
• Scan source API code frequently to identify APIs that do not belong in your system.

Conclusion

With the rise of API adoption and integration comes an increased risk of API attacks and vulnerabilities that can expose sensitive information and disrupt business operations. Shadow APIs pose hidden risks, since they operate outside of the organization`s security domain. To improve API security, use tokens to control access to services and resources, use encryption and signatures to ensure data privacy, and use an API gateway to authenticate API traffic. Organizations can ensure the security of APIs and safeguard their data and systems by addressing the risks of API attacks, vulnerabilities, and shadow APIs.

About the Author:

Dilki Rathnayake is a Cybersecurity student studying for her BSc (Hons) in Cybersecurity and Digital Forensics at Kingston University. She is also skilled in Computer Network Security and Linux System Administration. She has conducted awareness programs and volunteered for communities that advocate best practices for online safety. In the meantime, she enjoys writing blog articles for Bora and exploring more about IT Security. 

Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.