I initially wrote this post back in 2018. But it has extraordinary relevance in our current threat landscape. Now, 5 years and one enormous tech discovery later, imagine the application of GAI to this problem.

As we integrate more functionality into our product, it occurs to me that APIs probably represent the single most exposed vulnerability in enterprise computing today. Over the last few years, we have seen companies and organizations (at least those who seem to be interested) beef up their cybersecurity defenses against increasingly sophisticated cyber-attacks with improved firewall, intrusion prevention, data and endpoint protection technologies.

Which may push hackers onto new exploit paths that offer less resistance, like APIs.

The data breach at Panera Bread was caused by leaving an unauthenticated API endpoint exposed on its website, which created a major pipeline of critical customer information flowing from the website over an 8-month period before it was finally shut down in April of this year. This vulnerability allowed threat actors to suck up customer username, email address, phone number, credit card, and birthdate, data on more than 37 million customers, and drew attention to DevSecOps in general and API risk in particular.

Now, we love the benefits that APIs bequeath our dev teams as agile development cannot exist and expanded functionality cannot be so easily achieved without them, but the exposures have become enormous, and they have created a slew of new attack vectors including

1. Reverse engineering of API parameters to gain access to sensitive data,
2. Exploiting sessions cookies to bypass security fences and delivering false signals to app servers,
3. Eavesdropping on the unencrypted connections between an API client and its server to set up man-in-the-middle attacks,
4. Injecting JSON web tokens with malicious code resulting in auto-distribution onto the network, and
5. The delivery of invalid input parameters that result in an overload of an API-supported Web app and a subsequent DDoS flood.

According to a One Poll study, businesses on average manage 363 different APIs each, and two-thirds of those organizations are exposing their APIs to the public and their partners. In addition, dev libraries like API Hound contain over 50,0000 APIs make searching by functionality a breeze for agile developers who obviously want to benefit from integrating functionality from third-party provided services rather than building all the capabilities they need from scratch.

But, in spite of the intense focus in cybersecurity circles over the last two or three years on the need for more rigorous DevSecOps, the software development function is still woefully unrepresented in the software development process. A fundamental component in securing APIs lies in implementing solid authentication and authorization principles. For APIs, developers commonly use access tokens that are either obtained through an external process (e.g., when signing up for the API) or through a separate mechanism (e.g., OAuth). The token is passed with each request to an API and is validated by the API before processing the request. These tokens should require full authentication and authorization controls.

Core best practices should be required for all software dev teams and should include current developer awareness of today’s most common API vulnerabilities. The Open Web Application Security Project (OWASP) is a good and easily accessed source for this data. Monitoring traffic through an API gateway also can alert developers and DevSecOps folks to potential DDoS attacks so that they can throttle down to minimize risk before an attack occurs.

Getting these kinds of controls in place will not rob an organization of the speed with which their agile development teams can continue enjoying the benefits of rapid rollouts but will go a long way toward preventing the kinds of API attacks that are becoming all too common in the second half of 2018.

It turns out that we can have our cake and eat it too. We just must set the table a little more carefully.