The challenges of modernizing enterprise API infrastructure [Q&A]

APIs allow products and services to communicate with each other and have become essential to digital transformation projects as they make it easy to open up application data and functionality to third-party developers and business partners, or to departments within the enterprise.

Where legacy systems are involved though it's often necessary to modernize the API infrastructure to ensure things work smoothly and this can lead to serious challenges, especially where security is concerned.

We spoke to Shahar Binyamin, CEO at GraphQL security firm Inigo, to find out more about how enterprise developers, DevOps professionals and security architects can meet these challenges head on.

BN: At a high level, how big a problem is API security right now for enterprises?

SB: Enterprises are increasingly harnessing API connectivity to deliver new capabilities and user experiences more rapidly, but the security around those API integrations has become a growing concern. Wherever businesses rush in to capitalize on the benefits of myriad API connections without grounding their implementations in solid security practices from the beginning, attackers are now all but certain to take advantage of those shortcomings. A recent report on API security from Salt Labs bears this out, finding a 681 percent increase in API attacks over the past year, with 95 percent of enterprises suffering an API security incident during that same time period.

BN: What makes API implementations such an attractive attack surface?

SB: For attackers, there's a lot to like about targeting APIs as a path to infiltrating systems and breaching sensitive data. Nefarious clients can bombard API registration endpoints, attempt account enumeration to determine valid user information, make repeated login attempts, and tamper with parameters of interest. Against systems with weak access controls, an attacker that gains a foothold via an API exploit can escalate their access and potentially have the run of an enterprise’s data and services.

APIs are also a juicy target simply because many enterprises aren't defending them properly. The same Salt Labs report finds that 34 percent of enterprises have no API security strategy in place to speak of, and a sobering 85 percent confess that their current tools aren't effective at stopping API attacks. Unfortunately, API business logic offers complex avenues of attack that most traditional protections are ill-equipped to address, putting enterprises that haven’t prioritized API security in peril.

BN: As enterprises migrate from REST APIs to GraphQL, how does that affect or change their security strategy?

SB: GraphQL is a particularly advantageous upgrade over traditional REST API shortcomings. The open source data query and manipulation language for APIs enables enterprise developers to create faster and more stable applications that control their own data directly. That said, keeping GraphQL safe from attackers calls for a similar upgrade on the security front. In many cases, that hasn't happened.

With REST APIs, enterprise security engineering teams can easily monitor for many attack events that leverage HTTP methods, response status codes, sensitive API routes, and API parameters -- so long as the team is familiar with its APIs and has a complete inventory. For a specific example, a REST API query that uses the 'Get' HTTP method, targets a route with user ID information, and encounters a 403 Forbidden response code ought to trigger an alert. This is because repeated attempts may represent an attack activity. In contrast, however, GraphQL uses just a single route (such as /graphql), and HTTP methods aren't informative because the client’s actual intentions are all contained within the query payload. This example shows just one of the ways that GraphQL makes traditional security monitoring techniques not applicable. Instead, GraphQL calls for enterprises to implement a new observability layer designed to oversee and protect these APIs.

BN: What are some of the trickier components to GraphQL API security?

SB: GraphQL removes the traditional partitions dividing developer, security, and DevOps roles. Because GraphQL is so developer-focused, enterprise developers must become much more active in contributing to security. Adapting to this horizontal paradigm and implementing a strategy centered on holistic security and access controls is essential to success -- even more so than the particular security features an enterprise selects. Schema-based and database access controls must be closely integrated, and backed by rate limiting and other defenses against data scraping. Developers writing these code-based access controls require support from effective CI/CD tools, given the challenges of avoiding errors while dealing with GraphQL's ever-changing schema. A thorough and contextualized understanding of client API requests and responses is invaluable for leveraging detailed business logic and attack surface insights.

Enterprises that reach high-scale GraphQL usage will also need to adopt a security federated lens. Doing so enables enterprise architects to oversee and secure vast numbers of GraphQL API endpoints, which are managed by different internal teams often lacking organization-level understanding. These enterprises must also be ready to overcome abusive API calls using observability and query-level alerts, detect and mitigate attacks upon servers or data, and be prepared to defeat query-level GraphQL injections.

BN: Whose responsibility is GraphQL API security?

SB: GraphQL unavoidably asks developers to don their security caps, which they might find unfamiliar. Many access control and operations duties that formerly belonged to security and DevOps specialists will necessarily move into developers’ purview. And while GraphQL requires developers to implement defensive measures that go well past traditional API protections, the prize is to securely wield GraphQL go well beyond the limits of traditional APIs.

Photo Credit: Panchenko Vladimir/Shutterstock