Demystifying API Security

PUBLISHED ON April 6, 2022
LAST UPDATED Apr 06, 2022

We hear a lot of questions and concerns from customers and prospects these days about API security. It’s clear from these conversations that organizations are starting to think of API security as a unique, different, novel problem – something that requires new skills and new ways of thinking. With that in mind, I’d like to state a contrarian view here and say: there’s nothing really special about APIs.

The first and best thing we can do for you, if you’re just starting your API security journey, is to demystify APIs in general, and API security in particular.

What Are APIs? Just Software Doing Math

APIs are the building blocks of modern web applications, but there’s nothing really unique, specific, or magical about them. There are, of course, multiple tech stacks, and multiple standards, but all APIs are basically fancy remote procedure calls or fancy remote function calls. There is some piece of software sitting somewhere on a network, waiting to be asked to do math to something. That math might take the form of a database look up that puts some information back out on the wire. That math might be literal math, adding two to some variable and returning the sum. But at the end of the day, that’s all APIs are. And if you think of them that way, it makes the process of what to do next a little bit simpler to understand.

It Begins With a Dream

To simplify the security aspect of APIs, it helps to go back to the start.

All API development, all web app development, and in fact all software development, begins with a dream.

Some product manager somewhere writes a user story that says, “User X wants to do Job Y to achieve Business Value Z.” And if you’re an engineer, you’re going to take that dream, and you’re going to turn it into functioning, shipping production code. Some of that code’s going to be front end, and some of it is going to be back end. There may be API calls that your private clients use, and there may be public API calls that you expose to your user community.

And the biggest dream that’s driven the development of APIs over the last 5 to 10 years has been the DevOps revolution, and the DevSecOps game of catch up that followed. You can sum that dream up by saying “automate all the things.” Or more formally, the software developer wants to automate all the things to understand the production state of her applications.

Practically, this means machine-to-machine communication in a complex system of computers, nodes, services and so forth, with porous corporate boundaries and inter-enterprise transactions: API calls going to GitHub for pull requests, and Atlassian Cloud to look up Jira tickets, Slack for team communications, etc.

The Dark Side of the Dream

All of those SaaS tools are interconnected by and through APIs.

When you increase your functional footprints in an application, you also increase your attack surface. APIs, because they’re designed to be used programmatically by software robots to accomplish real business tasks, can also be used by software robots to do bad things. With that ever-increasing functional footprint and ever-increasing attack surface, security becomes paramount. And one thing I’ve learned over the years is that you can’t test security into software, you’ve got to design it from the ground up to be secure.

Demystifying API Security

There is no single silver bullet for API security, just as there’s no single silver bullet for web security or for application security in general. And many of the API security solutions out there are made out to be almost as mystical and mysterious as APIs themselves. But at the end of the day, each approach is one tool in your tool chain that can help you develop, test, publish, manage, and deliver functional APIs that are also secure APIs.

Getting Started With API Security

Where do you start? You’ll notice a theme in all our advice: security in depth. Start with perimeter security, and then build your overall security plan, and then bring your dev teams along with scanning and testing and secure coding practices in the SDLC.

The first thing that I always recommend is establishing perimeter protection. Cleanse HTTP requests on the way in to your infrastructure with a platform like ThreatX: A Layer 7 reverse proxy that can detect malicious attacks. That buys you time to get your house in order. Getting your house in order means inventorying and prioritizing your assets and your APIs. Focus first on anything that is a lucrative target: PII, health information, credit card transactions, etc. Next up is pen testing, SAST and DAST scanning, and mitigating the most severe findings.  But most important of all, do SOMETHING, and do it today!


For More Information

Bottom line: APIs are not that special; protect them as you would any other web app – from the start. Think protect, inventory, mitigate, and build an in-depth security program. Learn more about protecting APIs in our new guide, A Security Practitioner’s Introduction to API Protection: Five Requirements for Protecting APIs Against Attacks.

Tags

About the Author

Tom Hickman

Tom has a long track record of building and scaling product delivery capabilities at mid- and growth-stage startups. He served as the VP of Engineering at Edgewise Networks, where he led engineering through early releases of Edgewise’s zero-trust micro-segmentation product. While at Veracode, a leader in AppSec, Hickman led engineering through an Agile transformation and helped the company become a true multi-faceted AppSec platform prior to its acquisition by CA Technologies in 2017. Tom holds a B.S. degree in mechanical engineering from the Georgia Institute of Technology.