In the past, most applications were monolithic with self-contained logic and operational functionality. Modern applications are more likely to be built from dozens or hundreds of independent components and services (microservices architecture). This approach enables individual development teams to focus on the functionality of a smaller portion of the application and update their components independent of other development teams. 

The components communicate with others through an Application Programming Interface (API). Each API requires documentation to provide definitions and protocols regarding how to structure requests and responses. APIs can be private, for internal use, or public, to allow integration with partners. 

API Growth

APIs allow organizations to build applications more quickly. For example, instead of building a proprietary authentication routine, many organizations use Facebook, Google, or LinkedIn APIs to authenticate users. Outside of social media alternatives, a business can license an identity-as-a-service (IDaaS) provider’s API and connect their application to it.

GitHub currently includes over 2.2 million API repositories. Postman saw the number of API collections on its platform grow from 3.1 million in January 2017 to over 34 million in January 2020. 

API Security Concerns

From a security perspective, each API presents a new attack surface to hackers. Where security previously focused on an application’s user interface (UI), Gartner recently predicted that “90% of web-enabled applications will have more surface area for attack in the form of exposed APIs rather than the UI.” Like all software, poor API design or execution can introduce vulnerabilities to the application. Gartner estimated that in 2021, over half of all data theft incidents were traceable to unsecured APIs. Similarly, IBM Security X-Force reported that two thirds of the cloud incidents it investigated were related to misconfigured APIs.

Gartner’s survey ‘API Usage and Its Role in Digital Platform Growth’ found that API security ranked in the top three challenges to API strategy for 50% of respondents, followed by lack of skills and lack of API standards.”

Securing APIs can be challenging. Organizations have no control over third-party and unmanaged APIs. Like the challenge of managing open source components, they may not even have an inventory of the APIs used in their organization. 

Security vendor Salt reported a 681 percent increase in API attacks in 2021. Their customers top two concerns around API security are a “lack of investment in pre-production security” and a “lack of runtime or production security.” These attacks can be damaging to organizations.

• Hackers leveraged a leaky API on T-Mobile’s website to steal personal information on over 2 million customers.
• A vulnerability in a third-party API used to deliver and manage Symantec SSL certificates could allow an unauthenticated attacker to retrieve other organizations’ SSL certificates, including public and private keys.
• An Experian API that allowed unauthenticated queries allowed access to the FICO credit scores of most Americans. It even provided four “risk factors,” to help explain why a person’s score was not higher.

Common Attacks on APIs

Hackers can launch several different attacks using a vulnerable API. 

Denial of service – An attacker can easily overload an API’s processing capabilities, leading to a failure of the service. Using thousands of simulated users simultaneously sending requests at a “normal” level can make these attacks difficult to block. 

Injection attacks – A poorly executed API could process SQL commands or malicious code injected into an API. 

Man-in-the-Middle attack – If an attacker can intercept an API request or response between an end user and an API, they can steal information (including credentials) or modify the content of the request or response.

RBAC and ABAC exploits – Role-based access control (RBAC) and attribute-based access control (ABAC) detail the privileges allowed by a user or system, including viewing, accessing, and deleting data. Poorly defined or overlapping permissions can be leveraged by an attacker to escalate privileges and steal or modify data.

Business logic flaws – Legitimate business workflows may sometimes allow attackers to use them in a malicious way. For example, an attacker may deploy a malicious payload in a POST request to change pricing, currency, or delivery costs for an item.

To learn more about common vulnerabilities, readers can refer to the Open Web Application Security Project (OWASP) Top 10 risks to APIs. 

10 Best Practices for API Development

As the number of APIs in applications grow, security teams add these to their list of concerns. The following list of best practices offers a good starting point for API development.

1.     Develop a threat model – A good threat model will anticipate weaknesses in the design and implementation of the API, then assign mitigation controls directly to development, security, and operations personnel.

2.     Gain visibility – Teams must know which APIs exist in their applications to secure and manage them. Traffic capture and analysis and API fingerprint matching can help organizations discover and inventory their APIs. 

3.     Use strong authentication and authorization – Similar to a Zero Trust environment, each API request should require proper access control.. 

4.     Apply Least Privilege principles – Allow APIs only the minimum necessary privileges required to complete its required functionality.

5.     Always encrypt traffic – APIs handle payment information, user credentials, and other sensitive data. Encrypting API traffic can prevent a man-in-the-middle attack from capturing that data.

6.     Validate all input – As noted, an injection attack can leak data and allow malicious code execution. Ensure that any data is validated before processing. Use prepared statements, parameterized queries, or stored procedures whenever possible to prevent cross-site scripting and SQL injection attacks.

7.     Minimize the data you expose – All API responses should include only the specific information requested or the success/failure of the request. Make sure that keys and passwords used during development are removed before making the API publicly available.

8.     Test RBAC and ABAC rules continuously – As applications are updated ensure that security regressions are not introduced.

9.     Use rate limiting – To defend against denial-of-service attacks, teams should use rate limiting and limit payload size.

10.  Log API activity – No security plan is perfect. If your testing identifies weaknesses, use the log data to understand the root cause and harden your APIs.

Next Steps

Achieving API security requires organizations to understand the security threats and required mitigations. To do so at scale requires automation and integration with the API development life cycle. SD Elements provides teams with an extensive knowledge base of threats and weaknesses and maps those to specific and actionable tasks for implementation by development, security, and operations. 

If you are concerned about securing the APIs you use or simply trying to improve your security program, contact us to learn how SD Elements can help.