To ensure API security, organizations must inventory all APIs in use and ensure their definitions are complete, in addition to performing all the same application security activities they would for any application. The tooling may be different, but the tactics remain mostly the same as for web applications.
This piece outlines ways to evaluate an API security program, along with best practices and tools and processes to put a strong API security program in place.
The Challenge - Millions of Insecure APIs
As the software development industry moves more toward DevOps and away from monolithic applications, brand new APIs are being released constantly. Managing hundreds or even thousands of APIs can be quite complex and securing them is even more daunting.
Threat actors know APIs are often low-hanging fruit. APIs generally receive less security attention than web applications, so attackers tend to target them more often. In fact, most organizations do not have a current inventory of their microservices, meaning they cannot possibly be following a secure SDLC.
Insecure APIs are increasingly the root cause of data breaches. APIs often provide a direct line to our data, making them both mission-critical to organizations and lucrative to attackers.
Few developers secure their APIs adequately. Today’s software developers are not being taught how to ensure their services are secure. With little to no training on secure coding and design, this problem is only compounded.
Best Practices for API Security Programs
1. Build an API Inventory
You can’t secure your APIs if you don’t know where they all reside. It’s critical to begin now to build an application inventory that includes all APIs. Steps to build an application inventory include:
- Find out if an inventory already exists. If so, start with that. If not, inform the developers that an API inventory is in progress, and share it when completed.
- Ask each development team to list their APIs and apps, with links to the apps, environments and contact info for the team who maintains each.
- Look in the code repository to find applications that are not on the list. Also, check all pipelines to see if any apps and/or APIs are being published without your knowledge.
- Check for APIs and apps behind open ports. Run NMAP, masscan (network mapping) or something similar to scan on-premises data centers for any servers with Port 80 or 443 open. Check to see if a web app or API lives there.
- Review the cloud dashboard for applications that live in containers, virtual machines and PaaS environments.
- Do an external scan with a DAST tool to find any pages within the domain. This type of scan is sometimes called “spidering,” “cataloging,” “crawling” or “directory busting.” One domain may have thousands of different pages, and many of those will be their own unique application. Each application could have APIs hiding behind it.
- For every app found performing scans, use a web proxy to see if it is calling APIs. Record the apps and verify if they are on the list.
Some teams hire a consultant to do this work, which is often categorized as “application portfolio management.” If you decide not to hire a consultant, it is important make this a focused project. An API inventory is a large undertaking and cannot be done properly “off the side of someone’s desk.”
2. Set Up a Secure SDLC
All applications, including APIs, should follow a secure SDLC, which must involve performing at least one security activity during each development phase. Examples include:
- Requirements: Create a list of security requirements for the APIs, such as ensuring they are deployed behind an API gateway or using a service mesh (e.g., Istio or Consul).
- Design: Conduct threat modeling or a whiteboarding exercise to look for flaws in the design.
- Coding: Hold secure coding training. Give the developers a linter and perhaps a software composition analysis (SCA) tool, along with an IDE plugin and a SAST IDE plugin.
- Testing: Use a DAST on each API, bring in a pen tester and/or perform stress and performance testing.
- Deploy/maintain: Perform automated testing as the APIs are released using automated testing tools. Also, add monitoring and logging, and ensure every API is in the inventory.
3. Practice API Defense in Depth
Secure development is just one aspect of API security. It’s important to ensure APIs are deployed securely. Consider using:
- An API gateway: Any APIs that are publicly accessible should be behind an API gateway, with throttling and quotas enabled. An API gateway can also handle authentication and authorization. This additional layer ensures those who shouldn’t have access don’t. It also helps battle bots.
- A service mesh: If there are thousands of APIs, rather than hundreds or less, consider using a service mesh. A service mesh is an infrastructure layer that helps manage APIs and the traffic they create on the network. It also adds end-to-end encryption, with no code changes required.
Watch Out for Incomplete API Definition Files
The Open API standard’s security features only work if the definition file is complete. Too often software developers only fill out the parts they need to make their app run, making it impossible for the API to defend itself by performing input validation. It’s important to use a linting tool to ensure the dev team has filled out every possible field as part of the Open API definition file.
Start Securing APIs Now, Not Later
As more organizations switch to agile and DevOps environments, malicious actors are increasingly setting their sights on compromising our microservices. Beat them to the punch by:
- Building a complete inventory, which is key to any good application security program.
- Securing the SDLC to guarantee secure APIs are always released.
- Watching for incomplete definitions. You will never find a good scanning tool if the definition files are incomplete. Use a linter, fix what you find and then use a DAST tool.
Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in connection with such information, opinions, or advice.