Last Updated on January 18, 2024
Concern about application security is finally catching up to the urgent need for it. Yet just as orgs are wrapping their AppSec programs around the “old” way of leveraging APIs, the familiar server/browser/database architecture has morphed into a so-called “single-page architecture” where third-party API calls do most of the work.
What does the new API model mean for security? What new vulnerabilities does it introduce? And how can orgs get a handle on their escalating API-related risk?
To explain the new API economy, how it’s different and how it impacts security, Rob Dickinson, CTO at Resurface Labs, joined a recent episode of The Virtual CISO Podcast. The show’s host is John Verry, Pivot Point Security CISO and Managing Partner.
Applications are more API-centric than ever
If you thought your client/server web apps relied on APIs, that was just a warmup. Third-party API calls now drive the majority of web app computation.
John sums it up: In many instances now, application security and API security have become effectively synonymous.”
“APIs are the culmination of what we’ve been working towards in automating our business practices for the last 50 years,” observes Rob. “Fast-forward to, we have applications talking to other applications across the internet.”
Rob likens the new API model to the old-school practice of calling or faxing your stockbroker with an order. Then we moved to email- and browser-based ordering. Now it’s one app talking to another app and then that app transacting with another app and so on—all potentially at the same time.
Take the example of your Alexa device processing a song request via the Alexa cloud, which then communicates with the Spotify cloud, which handles the response back to you. Each of these API calls makes something specific happen: changing a value, issuing an order, etc.
“If you’re coming at this from a development perspective or a more technical perspective, the thing to clarify here is that when we’re talking about the API economy or API security, we’re talking about APIs calling other interfaces across a network,” Rob clarifies. “There are lots of other kinds of APIs, like Java low-level collections APIs and things that the STL [Standard Template Library] gives you in C++. The Python language is kind of an API. But that’s not what we’re talking about here.”
“It’s just one piece of software calling another piece of software over the internet,” continues Rob. “It’s not web servers and web browsers. It’s a generic kind of client; it’s a generic kind of server. The API call is the transaction. It’s the handshake between those two systems that says, ‘Please do this bit of work for me.’ And then there’s the result that comes back from that.”
The new API jargon
If business and technical stakeholders are talking about APIs, what are the right terms to use for unambiguous communication? How do you clarify the API usage(s) in question? Are API calls now called endpoints? With a single-page architecture at the front-end?
“I think the short answer, which you might not like, is, yeah, it’s gotten really hard,” admits Rob. “So having gone on this journey where we used to talk about web-specific architectures, three-tier architectures… Those were fairly specific blueprints about what that meant and what those zones of responsibility would be and what technologies would be involved in different parts of the stack.”
A lot of that view still applies. But what has shifted the most between web-first and API-first apps is the client. With the former model, there was always a trusted client through which you interacted with the application. You weren’t connecting directly to the server-side middleware or to the database.
But with something like Twilio that’s 100% API-based, there is no trusted client. You can call Twilio from any programming language or any kind of app. You gain efficiency and flexibility, but you lose significant control because you no longer control a trusted client.
“Instead, you’re saying, ‘Here’s this REST endpoint, here’s this GraphQL endpoint. As long as you do the right thing, we’ll try to do the right thing. And it’s Game On!’,” Rob summarizes. “It’s a new spin on who owns what and what parts are easily replaceable.”
What’s next?
To hear this cutting-edge show with Rob Dickinson, click here.
Is your AppSec strategy ready for APIs? This blog post frames the issues: It’s Hard to Spell Security with API (Translation: You Need an AppSec Strategy)