How to Improve the Security of Your APIs from the Get-Go
APIs are quickly taking over the web. According to Gartner, by 2022 APIs will be the most targeted attack vector on the enterprises. In this article, we take a look at how you can improve the security of your APIs by locating and remediating some of the most common API vulnerabilities in your OpenAPI contract files.
APIs Are Taking over the World
The picture of web applications is changing: API usage is on the rise. Most web applications these days are based on a UI that uses API operations to call to the backend servers for resources and data.
Same goes also for mobile applications, Internet of Things (IoT), business integration projects — all have APIs enabling them. Akamai estimates that about 83 percent of web traffic is now API traffic.
Even the way systems are put together is veering towards APIs. The shift to microservices architecture takes API proliferation to a whole new level. Now individual containers and functions also call APIs to work with the rest of the system.
Why WAF Is No Longer Enough
The changing application landscape also changes the approach to securing it. Previously, the entry point to an organization’s network architecture was through applications, with a thin web application layer and running on dedicated servers. This made it relatively easy to maintain security by setting up a web application firewall (WAF) to protect the application servers.
However, with the rise of APIs, the picture today is very different. Now, there is no nicely defined single entry point to the network architecture. Instead, the entry points are the plethora of APIs that call the backend to provide the functions of the application.
Even though REST APIs are HTTP-based, if you assume that a WAF can protect the API traffic as well, you are in for a nasty surprise. WAF technology typically focuses on known attack types and lacks granular understanding of the specifics of each API design and implementation.
Thus, WAF simply has no way to tell hacking API calls apart from legitimate API traffic, so it cannot weed them out, but treats everything equally.
API Security Is Teamwork
Many APIs start their life simply as an internal implementation detail. Business needs a functionality to appease the demand, and developers strive to deliver the functionality as quickly and efficiently as possible. Unfortunately, this often means that security takes the back seat because of:
- Time pressure
- Lack of understanding what is involved in API security
- Disconnection between developers, operations, and security specialists
Luckily for the industry, a common format has emerged and become a widely adopted way of documenting APIs. Originally called the Swagger specification, in 2016 the specification was renamed as OpenAPI Specification (OAS). The project is maintained by the OpenAPI Initiative, a Linux Foundation project with 35 corporate members including Google, Microsoft, eBay, 42Crunch, and many more.
A common standard with large tooling support enables developers, operations, and security people across teams to speak in common language. Instead of deducting the intent of an API from its behavior or source code, all teams can use the standard OpenAPI contract to communicate clearly.
One of the key functions that the standard contract can enable is API security. When all teams building both the API and the infrastructure the API is going to sit in can clearly communicate the intent, requirements, and outcome, it is also easier and more reliable to uncover, understand, and mitigate security risks.
Everything Starts with the API Definition
Because APIs now form the point of entry to your network, this puts the quality and security of the API definitions in the spotlight. The starting point for the API security is the OpenAPI definition itself.
Just read a few recent issues of the weekly API security newsletter, and it comes apparent that attackers can find and use APIs designed for backend use only, and circumvent them, for example, by sending unexpected payloads.
If your API definition has gaping security holes, applying security measures on top of that just creates a ticking time bomb. The first step is to make sure your API conforms to security best practices. This is where API Contract Security Audit can help.
API Contract Security Audit
API Contract Security Audit tool at APIsecurity.io is a quick and free online resource that you have at your disposal. With Security Audit, you can check that the OpenAPI definition adheres to the OpenAPI Specification and catch any security issues your API might contain.
You can start auditing your APIs from early on and keep iterating as you develop them further. This way you can bake security best practices into the API development process itself instead of reducing security to an afterthought. In addition, Security Audit also flags issues in your API’s structure or logic, helping you improve the overall quality of your API.
While there is no single silver bullet for API security, ensuring proper API design and making auditing its security part of your API development process is a huge step towards more secure APIs that every organization needs to take.
API Contract Security Audit tool does not persist your files or reports, so you don’t have to worry your APIs being stored somewhere out of your control.
How Does It Work?
Security Audit currently supports OpenAPI v2 definitions in .json format. This example uses this Security Audit to improve the security of the API specification petstore-expanded.json from OpenAPI GitHub examples.
- On the API Contract Security Audit page, click the Browse & Upload button, and browse to the OpenAPI file you want to upload to the tool.
Once the file is processed, the tool displays an audit report that includes the overall score and information about the areas covered:
The report shows that petstore-expanded.json meets all the OpenAPI format requirements, but you can also see that the overall score is just 40 out of 100. This means that there are quite a few outstanding issues in the Security and Data validation
2. Click the sections on the left-hand side to see the specific issues the audit found. For example, in the Transport section, petstore-expanded.json has five issues related to the API and its operations accepting unencrypted (HTTP) traffic.
3. If you click the listed issues (here “API accepts HTTP requests in the clear”), you can see further details. The report shows the exact problematic place in your OpenAPI contract, information on the potential exploit scenario, and recommendations on how to fix the issue:
4. Follow the report’s recommendations and fix the indicated issues in your API definition (using your editor of choice). This example makes the following change :
|
1 |
"schemes": [ "http" ], |
to
|
1 |
"schemes": [ "https" ], |
5. Save your API file and audit it again. Back in the Security Audit tool, click Audit another API button at the top right, and re-upload your API file.
Here, while multiple other issues still remain in petstore-expanded.json, you can see that the Transport section is now good.
You can go through the other sections one by one and fix the remaining items.
If you find any issues that you think have not been properly detected or reported, you can click the Contact Us at the top menu to provide your feedback.
Summary
API security challenges can be tackled by shifting security to the left, all the way to development and design. OpenAPI Specification is the industry standard that enables locked-down API design and common language shared between architects, developers, operations, and security teams.
Feature image by Gerhard Gellinger from Pixabay.