As we move into new business strategies or transition to new enterprise deployment models CISOs must constantly look to update the risk register and security program controls.  The function that most companies have moved to recently is application programming interface (API).  The benefits of publishing a set of definitions or protocols to interface with has incredible business benefits but at the same time makes it easy for cybercriminals to automate attacks.  As with all transformation efforts we need to establish a path to mature the cybersecurity of both the developers coding and the APIs they are publishing.

When working with developers it is important to leverage industry standards and one of the best resources is OWASP Top 10.  Recently they have published updated and new lists for both APIs and large language models (LLM).  By providing these most common coding risks to developers they can conduct training to ensure everyone knows how to avoid them and build in technical controls to rapidly identify and remediate any vulnerabilities that make it into production.

When thinking about secure coding for APIs you should also understand the more technical aspects of both posture and runtime issues. Posture problems include shadow endpoints, unauthenticated resource access, sensitive data in a URL, permissive cross-origin resource sharing (CORS) policy and excessive client errors.  Runtime problems include unauthenticated resource access attempts, abnormal JSON properties, path parameter fuzzing attempts, impossible time travel and data scraping.

Next, we need to look at how to build out the guardrails to make sure the APIs are protected.  To do this the first challenge is to have an inventory of them.  You can’t protect what you don’t know about and with rogue, zombie and shadow APIs you need process and technical discovery controls in place.  Once you discover them you can determine where the process failed to make sure they were covered by your program.

Once you are confident of your inventory, you need to ensure you have visibility on the policies as well as posture, vulnerability detection, attack detection and response and validation testing.  How you accomplish this can be complex if you have a hybrid environment that includes IoT and legacy systems.  While there are still traditional attacks that a web application firewall will defend against, you will typically still need an API-specific security capability to help with techniques that include business logic attacks.

API Abuse

Another area that needs situational awareness is the detection of API abuse.  One of the concerns with APIs is how fast they can scale as they are designed to facilitate automation.  Two separate and recent examples of major incidents include 15 million and 49 million records/profiles being scraped through poorly monitored APIs.  These numbers could result in the need to make public announcements of breach or compromise and if the company is public they could be required to file a cyber incident 8K under the new securities and exchange (SEC) rules.

Next comes some of the basic protections.  As they are public-facing they should be behind your DDoS protections.  You should segment the resources they connect to as they are highly targeted.  You need to include API analytics in your SOC playbooks (i.e. abuse detection).  Finally, you must work with compliance to track any emerging legislation.  Note most of the current legislation is a subset of other standards like PCI vs purely API-focused.

As you think about how to ensure your APIs are within your risk tolerance, ensure that you have a sound understanding of your inventory and the data associated with them.  You also need solid controls to prevent coding that allows security vulnerabilities into production.  Finally, you need strong situational awareness that feeds into a threat-hunting team that understands new threat vectors like business logic abuse.