Platform Features
By Need
By Industry
Partner Program
Our Partners
Key Alliances
Resource Center
Key Takeaway
Given the importance of securing APIs, it’s essential to follow the industry proven best practices. In general they relate to four main areas of focus – API discovery, posture management, runtime protection, and API security testing. We focus on knowing how many APIs you have, how to protect them, and how to test them for errors. Keep in mind that this list of best practices goes beyond the status quo of deploying an API gateway and/or web application firewall.
Application programming interfaces, or APIs, present a lucrative attack surface for malicious actors. However, securing APIs has become quite challenging as the number and variety of APIs has grown rapidly. The complexity of API configurations has also increased at the same pace. Once upon a time, Simple Objects Access Protocol (SOAP) was the de facto protocol for web APIs. Fast forward to today, and protocols like GraphQL and REST APIs are changing the game.
In response, API security best practices continue to evolve. They offer everyone from DevOps teams to architects, QA and security managers a way to improve their API security posture. In this article, we will explore the four core focus areas for API security, API security testing, API discovery, runtime protection and posture management. We’ll also cover some additional best practices that will help you protect your APIs.
Industry research reveals that 98% of enterprise leaders believe APIs are essential to their organization’s digital transformation. Almost two-thirds of organizations rely on APIs to improve their collaboration with partners. Sixty percent share APIs among internal development teams to speed up the delivery of products and services.
The pervasive nature of APIs creates inherent security risk. An API, after all, is a direct path into software and data. In an earlier era, an enterprise could rely on “security through obscurity,” with access to data masked by opaque, proprietary interfaces.
Today’s APIs directly expose digital assets to malicious actors through standardized, open protocols. Many organizations publish their APIs, giving hackers the address of sensitive data and a map that shows how to access it.
API Security is the use of all security practices relating to a program based API that are commonly employed. API security consists of ensuring the security of the data and information stored on the API. These attacks exploit a vulnerability in an API or use reverse engineering.
How serious can an API vulnerability be? The answer depends to some extent on the nature of an organization’s APIs and what they represent. In some cases, an API might connect to a relatively unimportant data source. So securing it may not feel like a high priority.
However, any intrusion into an enterprise through an API has the potential to become a serious cyber incident. Once an attacker has penetrated the infrastructure via an unprotected API, he or she can move laterally across the network. This allows them to breach more sensitive data.
Alternatively, the API might provide access directly to critical data. If API usage is not throttled, an attacker may be able to use an API’s “GET” function. This allows them to “get” a great deal of information on an unauthorized basis. Or, an API attacker can inject malicious code into applications. They could also simply disrupt operations by flooding the API with requests for service. For example, an API-based denial of service (DoS) attack.
Given the importance of securing APIs, it is essential to approach API security in an organized way. Notably, follow the industry proven best practices is further recommended. Such practices vary greatly across enterprises. But in general they relate to four main areas of focus – API discovery, posture management, runtime protection, and API security testing. In other words, we focus on knowing how many APIs you have, how to protect them, and how to test them for errors. Keep in mind that this list of best practices goes beyond the status quo of deploying an API gateway and/or web application firewall.
APIs figure prominently into the software development process. Developers use APIs to connect the applications they are building with services and data sources fronted by APIs. The risk here is that the developer will inadvertently add vulnerabilities to an application by not integrating API security and testing.
Waiting until the application is in production is too late to start looking at whether the APIs it uses are secure. By then, the application is already exposed to risk, and the costs of remediation become prohibitive. Instead, the best practice is to testing APIs early and often. The goal is to make API security policies part of the DevOps workflow and continuous integration/continuous deployment (CI/CD) pipeline.
For example, before coding a connection to an API, the developer should be aware of security policies affecting that API. Like, does it request data encryption or use a TLS certificate? As apps evolve, developers should be able to test and validate an API’s security as new code gets released.
Success in adopting this practice is partly a matter of tooling. Developers need the right tools to make API security and testing part of the SDLC. There may also be organizational issues to resolve.
For instance, developer, testing, and operations teams, must agree that API security is a priority in the SDLC. Only by working together will they make security a natural part of the development lifecycle. Discover how the Noname Security approach API Security testing makes this a reality.
It is only possible to secure APIs if their existence is known to relevant stakeholders. It is quite common, however, for security managers and architects to find a previously unknown API in use in their environment. Even with an API gateway or web application firewall (WAF), organizations have limited visibility. “Wow, I didn’t know that API was even there!” is a more frequent utterance than many people want to admit.
It is a best practice, therefore, to find and inventory APIs. That way, “rogue APIs in the wild,” as some security practitioners call them, can be identified and addressed. Differentiating between APIs used internally versus externally is also important. This practice is known as API discovery.
A good API discovery solution will not only be able to uncover shadow, zombie, and rogue APIs, it should also be able to identify every type of API in your environment. This includes HTTP, REST, GraphQL, SOAP, XML-RPC, JSON-RPC, and gRPC.
Once you have an accurate inventory of your APIs, its time to evaluate them for misconfigurations. Many cyber attacks gain entry as the result of misconfigured networks, API gateways, or firewalls that broker and protect API traffic. You need to be able to scan all possible sources to detect vulnerabilities. ‘Sources’ include things like log files, configuration files, replays of historical traffic, etc. This is what the industry refers to as posture management.
Improving your API security posture also entails having a visibility into the types of data that traverse your APIs. With that said, it is wise to classify APIs that are in use and understand which ones access sensitive information. Identifying the sensitive data within your organization, such as customer PII, credit card numbers, etc., is key to maintaining compliance.
APIs have to be kept secure at runtime. The recommended tactics for achieving this goal include monitoring APIs in production and keeping track of known vulnerabilities. Known as runtime protection, this type of monitoring involves tracking API use in real time and flagging anomalies that would suggest an attack is underway. More sophisticated tools use artificial intelligence (AI) and machine learning (ML) to evaluate traffic against access control settings you’ve established.
Runtime protection tools can also track known API vulnerabilities. If any are discovered, alerts are issued to admins that certain APIs need to be patched or replaced. This falls into the broader work of threat detection and response. API security should be part of these processes.
It’s imperative that you identify all related users and devices. We call this API authentication. Authentication happens at both the entity and the user level. For entities, an API key is used. API keys are essentially numeric identifier that authenticates a requesting entity or device.
When requesting access to the API, a user will submit the key to the API security solution. The API security solution will, in turn, either grant or deny access to the API based on the validation of the API key. It’s important to note that API keys were created more as an identification tool versus a security control. This is because API keys do not include information about the user making the request.
For user authentication, this typically requires a token in the API call so that the service can validate the user. Use standards such as OAuth 2.0 , OpenID Connect and JSON web tokens to authenticate API traffic.
While authentication focuses on gaining access to the party, authorization dictates where they can go and what they can do at your party. Leverage API authorization tools to define access control rules or grant types that determine which users, groups and roles can access specific API resources. Always follow principle of least privilege (POLP).
API rate limiting is another layer of access control. It’s a way for companies to control the number of requests that can be made to their APIs. It is a common practice in the industry and it helps to prevent abuse of APIs. The most common way of implementing API rate limiting is by using a token-based authentication system.
The API rate limit can be set by using HTTP headers or by using an API key. The header method allows for more flexibility, but it requires more work on behalf of developers who need to implement this feature into their applications.
This is an important measure to prevent both malicious and non-malicious consequences. In a scenario with malicious intent, back actors can be trying to consume all of the resources of your API(s).
Let’s imagine that an API is being used by multiple businesses and one of the businesses using the API may make an excessive number of API requests. Despite not being malicious, this can cause other businesses to encounter limited or no response to the API calls they make. In either scenario, it’s important to have APIs with properly configured resource and rate limiting so it stays available to its clients. You can learn more about rate limiting here.
Developers need the latest techniques to protect APIs to prevent hackers from obtaining access to their systems. Set Google alerts for API and cybersecurity related keywords on industry websites, blogs, and other related platforms. By staying on top of current online threats, developers may configure their APIs accordingly so that they can thwart current attacks. Therefore, reading trustworthy sources such as the OWASP list of 10 vulnerabilities may assist you to stay current.
APIs are an integral part of the enterprise software ecosystem. They are the key ingredient in digital transformation. APIs can also be a source of cybersecurity risk. Their open nature makes them a target of hackers who want to access the data and apps that sit behind them.
API security best practices make it possible to mitigate a great proportion of API risk. To work, these recommended tactics focus on the complete API picture. Starting with the SDLC and continuing through API inventory tracking and monitoring of APIs at runtime. An organization that pursues these best practices is well positioned to have a strong API security posture.
Learn four critical gaps of commonly used tools such as WAFs and gateways as well as what it takes to build a comprehensive API security program.
After four long years since the original guidelines were created, the Open Web Application Security Project (OWASP) has now updated their Top 10…
As your organization’s use of APIs expands, your attack surface expands with it, creating new security challenges — and opportunities for attackers.
Harold Bell
Harold Bell was the Director of Content Marketing at Noname Security. He has over a decade of experience in the IT industry with leading organizations such as Cisco, Nutanix, and Rubrik, and has been featured as an executive ghostwriter in Forbes Technology Council and Hacker News.
All Harold Bell posts All of Harold Bell's postsExperience the speed, scale, and security that only Noname can provide. You’ll never look at APIs the same way again.
Certified for your security needs.
