We’re hearing a lot of questions and concerns from current and potential customers these days about API security. It’s clear from these conversations that organizations are beginning to think of API security as a unique, different, and novel problem, one that requires new skills and new ways of thinking. With that in mind, I would like to express a contrary opinion here and say: there’s nothing really special about APIs.
The first and best thing we can do for you, if you are 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 technology stacks and multiple standards, but all APIs are basically fancy remote procedure calls or fancy remote function calls. There’s a piece of software somewhere on a network, waiting to be asked to do math on something. That math could take the form of a database lookup that returns some information to the cable. That math could 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.
start with a dream
To simplify the security aspect of APIs, it’s helpful to go back to the beginning.
All API development, all web application development, and indeed all software development starts with a dream.
Some product manager somewhere writes a user story that says, “User X wants to do work Y to achieve business value Z.” And if you’re an engineer, you’ll take that dream and turn it into working shipping production code. Some of that code will be front-end, and some will 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 driving API development in the last 5-10 years has been the DevOps revolution and the DevSecOps game of catch-up that followed. You can sum up that dream by saying “automate all things”. Or more formally, the software developer wants to automate everything to understand the production status of their applications.
In practice, this means machine-to-machine communication in a complex system of computers, nodes, services, etc., with porous corporate boundaries and cross-company transactions: API calls going to GitHub for pull requests and Atlassian Cloud for search Jira. tickets, Slack for team communications, etc.
the dark side of the dream
All those SaaS tools are interconnected by and through APIs.
When you increase your functional footprints in an application, you also increase its attack surface. APIs, because they are designed to be used programmatically by software bots to perform actual business tasks, can also be used by software bots to do bad stuff. 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 software for security, you have to design it from scratch to be secure.
Demystifying API security
There is no silver bullet for API security, just like there is no silver bullet for web security or application security in general. And many of the API security solutions out there are made to be almost as mystical and mysterious as the APIs themselves. But at the end of the day, each approach is a tool in your toolchain that can help you develop, test, publish, manage, and deliver. functional APIs that are also sure API.
Get started with API security
Where do you start? You’ll notice one theme running through all of our advice: security in depth. Begin with security perimeterand then build your overall security plan, and then bring your development teams along with scanning, testing, and secure coding practices into the SDLC.
The first thing I always recommend is setting up perimeter protection. Clean up HTTP requests on the way to your infrastructure with a platform like ThreatX: A Layer 7 reverse proxy that can detect malicious attacks. That gives you time to put 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. The next step is the penetration test, SAST and DAST scanning, and mitigate the most severe findings. But most important of all, do SOMETHING, and do it today!
For more information
Bottom line: APIs aren’t that special; protect them as you would any other web application, right from the start. Think about protecting, inventorying, mitigating, and creating a comprehensive security program. Learn more about securing APIs in our new guide, Introduction to API protection for a security professional: five requirements to protect APIs against attacks.
*** This is a syndicated Security Bloggers Network blog from Web Application and API Protection Blog written by Tom Hickman. Read the original post at: https://www.threatx.com/blog/demystifying-api-security/