To find out more about critical issues and future solutions in the API security space, I talked with Dmitry Sotnikov, Chief Product and Marketing Officer at 42Crunch. His company’s products are based on the open source OpenAPI Specification, and they are a member of the OpenAPI Initiative — part of the Linux Foundation.
What Makes API Security Different from Web Application Security?
Traditional web application security is relatively monolithic, with web apps being hosted on vendors’ servers. Users most often use browsers to interact with the server. There’s some rendering, some small interactivity, but most of the functionality is on the server-side. The attack surface is the web browser. This allows browser and session attacks, SQL and other injections, and actions related to user input. It can be serious, but it’s relatively limited.
However, in the past few years, there has been a dramatic change in the way apps are architected. Applications are now massively desegregated, with innovations like Single Page Applications (SPA) — which interact with the web browser by dynamically rewriting the current web page with new data from the webserver, instead of the default method of the browser loading entirely new pages. So there are now applications in the browser, and there is a lot of the logic now in the browser. Mobile applications behave in a similar way, executing locally on a user device and exchanging data with the backend via API calls.
This is new. And there’s more. The back end changed as well.
The microservices revolution happened, with Kubernetes leading the way. The actual application — the back end — is not functions and objects, but a set of services talking to each other via APIs. Cloud native is also trying to re-use whatever 3rd party services are available. For example, using Stripe APIs to process credit cards, Twilio APIs to send SMS messages, and lots of other APIs for all kinds of services and integrations.
So now, instead of a relatively static attack surface, we are in a world where one app can have hundreds of APIs. A lot of these APIs just give you data, which is internal to the application. In other words, data access — which never used to be part of some external interface — is now very exposed.
The attack surface expanded dramatically, and the ability of the attacker to get inside the application changed dramatically.
Before, when developers needed to create a different class or a different set of objects, they would just create them. Now, they do the same with microservices. Which means they are constantly adding external attack surfaces.
This trend of abstracting away the infrastructure is only going to increase and lead to more APIs and functions getting exposed.
How Does Using the OpenAPI Specification Enhance API Security?
Unlike applications in general, APIs can be structured. Back in my computer science days in college, one of the things that we were looking at was trying to build formal models of applications. In fact, my Ph.D. thesis — that I’ve never finished! — was on this very topic. Is it possible to create a formal model and verify that a particular application is functionally correct and secure? Unfortunately, this is extremely hard to do. Basically impossible for arbitrary real-life applications.
However, when you start defining APIs — this is where the OpenAPI Specification can be extremely useful — in a machine-readable format, you can use software to work against those specifications, and find deficiencies in the way they are defined, and find potential flaws and issues.
If you have a formal machine-readable model showing how the API is supposed to work based on the inputs it is written for and the expected outputs, when behavior is different from the model then you can prevent that behavior from happening.
The OpenAPI Specification emerged from the need to document APIs, but because it is machine-readable and because it has gained such a wide industry support, you can use it with security.
What Problems Do You Have with the OpenAPI Specification?
The OpenAPI Specification helps in a wide range of areas, and, as I’ve pointed out, is very good at significantly increasing API security. It does have two issues, however, that the community is working to improve:
- The OpenAPI Specification is very permissive, so you can use some features, but it’s fine if you don’t use others. For example, you can define paths and verbs and parameters, but skip defining types and formats of the data coming in or going out. Thus, it’s quite possible for developers to use the OpenAPI Specification but not go into enough detail to make it comprehensive.
- OpenAPI Specification is still evolving, so some of the API behaviors that exist out in the world today are not integrated yet — especially around security. For example, Mutual TLS authentication (mTLS) is still not in the specification, so there’s still no way to define that. That’s coming in the next iteration of the standard. Same thing with JSON web tokens (JWT). Most modern REST APIs today are using JWT for security, but it is still not included in OpenAPI Specification. Same thing with any rate-limiting rules. The list can go on and on.
The more the OpenAPI Specification aligns with current API practices, the more usable it is.
What Are the Top 3 Most Common API Security Vulnerabilities?
I would really recommend anyone interested in common API security vulnerabilities and the ways to mitigate them to check out the APIsecurity.io website and subscribe to its weekly newsletters. There is hardly a week without API vulnerability stories in the news and we can learn a lot from them.
The Open Web Application Security Project (OWASP) has recently released its OWASP Top 10 API Security vulnerability list for developers and security teams. It represents a broad consensus about the most critical security risks to APIs and is a great educational resource.
Beyond specific vulnerabilities, the bigger issue that I see is that in a lot of companies there is no way to find all the APIs and enforce security across all of them. In a lot of cases, there are very basic things missing from a security perspective. For example, 42Crunch completed a recent project with a large manufacturing firm in the US. For just one of its departments, we ran an API discovery process, and we found about 700 APIs. More than half had no security at all. More than half were not protected at all! Very basic solutions, like authentication, encrypted traffic… were simply not implemented, not even thought about.
The recently released 2020 Unit 42 IoT Threat Report by Palo Alto Networks’ Unit 42 showed that 98% of all IoT device traffic is unencrypted. That includes very sensitive devices, like medical devices in hospitals. It’s not even weak encryption; the devices are lacking encryption completely.
Where Will API Security Be in 3 Years from Now?
My expectation — and a huge part of 42Crunch’s focus — is that 3 years from now, API security will basically be embedded into API design, development, and DevOps tooling. Security won’t be a separate team with their own tools doing their own stuff. Security will stop being just a production issue. It will become embedded in the whole lifecycle.
When you’re designing APIs, your tools will be smart enough to help you design APIs securely (like you can do with the OpenAPI extension in Microsoft VS Code today). When you’re building and debugging your APIs, tooling will help with security. Testing will be functional testing and security testing. And run-time won’t just run your API. It will follow security models to make sure that your API behaves as expected.
API security will become a part of the whole API lifecycle.
Feature image via Pixabay.
This article originally appeared here.
