History repeats itself. Today we can apply that statement to the explosive use of APIs and the emergence of API scanning and testing tools by looking back at the early days of web applications and the related testing tools. Early-era web apps were immediately targeted by threat actors. Manual security testing efforts quickly evolved to a wide range of automated testing tools. Web testing tools became a staple for security teams and threat actors alike.
Today, API-first development methodologies are introducing a wide range of exploitable holes. Unlike web apps, APIs are designed for machine-to-machine communications, relying on pointers to achieve the desired result, making it difficult for a developer to uncover potential security gaps either manually or using a current web app testing tool. To help find and remediate API security holes, best practices for API documentation and the use of specification frameworks have begun to take hold. These steps centralize the API schema, making it easy for all teams to find, test and address security gaps.
As seen in the era of web apps, new API-centric tools like Kiterunner and Nuclei have emerged to help automate the discovery and testing of APIs and related resources. Unfortunately, well-defined API documentation stored in a centralized framework and automated scanning tools simplifies the process of finding an exploitable hole. In a recent customer engagement, odd behavior against their APIs showed that Nuclei was scanning their APIs from an unknown IP address. The traffic was blocked accordingly.
View our API Specification Framework Security Best Practices Ebook to learn more about these new scanning tools, how to detect them, and how to protect your APIs.