There are three strategic steps to securing APIs, but the process cannot start with implementing an API gateway or other API security products. First, enterprises need to know exactly what they're trying to secure, VP Analyst Mark O'Neill said during Gartner’s Application Innovation and Business Solutions Summit.

APIs present a large potential attack surface and various attack vectors like insecure API key storage, for example. Gartner recommends organizations approach API security beginning with API discovery, or building an inventory of all APIs an organization uses..

The challenge with discovering APIs is that there isn't typically one place to look for them, O'Neill said. Internal teams may be building some APIs, and some may come from code repositories like GitHub.

Organizations should also look at web applications they use during the API discovery phase. O'Neill recommends they "crawl those web applications, follow the control points, and find where APIs are being called."

There may also be API management tools where an organization's in-use APIs are registered. However, "none of these methods are exhaustive," he said.

"If you only look at the APIs that are registered in your API management solution, there are likely to be many internal APIs that are not registered there. And there may also be third party APIs that you use that may have security issues that are also not registered" in the API management tool, O'Neill explained.

To that point, Gartner suggests companies dig through multiple places to ensure full discovery of all APIs in preparation for successfully securing them.

After all an organization's APIs are discovered, the next step is to perform both active and static security testing on each API.

Active testing includes sending requests to the APIs and checking its responses. Static testing deals with looking at the API definition itself. "Is that API definition locked down? Is it strong enough in terms of the checks that are in place for parameters?" O'Neill said.

For example, if an API definition simply says parameters — like account numbers or addresses — are a string, "obviously, that's quite loose." Each parameter should have a certain length, format, etc., and this helps limit the attack surface, he explained.

After testing comes calculating risk. Enterprises should consider what vulnerabilities they've found and the risks posed by those weak spots "in terms of how many applications are using the API and the profile of the users," he added.

If using third-party APIs for sending out text messages or hiring, for example, O'Neill recommends testing those as well and talking with the provider about the security of those APIs. "A breach of those APIs can then impact you too," he said.

The final step is implementing fine-grained API access control, according to the analyst firm. "You're also implementing layered security ... where you're not only checking at the edge, [but] you're also looking at internal API traffic," O'Neill said.

He also urged organizations to not just rely on providers' assurance that their APIs are built securely.

"The service behind the API, of course there's code there that's running the service. And you might put parameter validation there, but things like blocking denial of service and others should be done in front of that API, not in the code of the service itself," he explained.