New security for new API frameworks

From generating personalised weather reports to seeing your bank statement, today’s digital experiences are powered by application programming interfaces (APIs) – the connective glue that brings together all the elements that help applications and databases communicate effectively and share data seamlessly.

The development and usage of APIs have grown exponentially in recent years as organisations accelerate modern software development that improves internal operations, and enhances customer and partner engagement. A recent global Forrester survey shows that 78% of respondents believe the adoption of APIs is important for their company to stay competitive in the market.

As decision makers prioritise customer relationships or improved internal operations, API adoption in 2022 and beyond will continue to expand. However, business leaders need to understand that API-driven innovation creates additional cyber and business risk. While organisations want to adopt APIs, they need to understand how APIs work and the ways in which the technology can be exploited. Further, development teams need to be aware of the risks associated with newer API frameworks and programming languages, and take steps to mitigate potential security incidents.

An inherent risk

As the volume of APIs multiplies each year, they are a rich target for malicious actors. With  development happening so quickly, many APIs are released into production before they can be appropriately reviewed, catalogued, and assessed for security issues. And because modern APIs are self-documenting, they can actually deliver valuable intelligence for bad actors to exploit. They essentially serve as a blueprint, providing insight into internal objects and even internal database structure.

Moreover, just a short step past the API lies the data store itself. The fact that organisations often trust application accounts, which access data more than interactive user accounts, further heightens the risk.

In some cases, APIs need to be shared with third-party vendors to enable functionality, but organisations need to appreciate the risks that may introduce. By opening up access to internal applications and data, the lines of data ownership and accountability are blurred. An organisation’s risk will grow accordingly if the third party adopts less stringent cybersecurity standards than itself.

Securing new API frameworks

Newer API frameworks like GraphQL and gRPC are growing in popularity as businesses demand more diverse, high-performance applications and engineering models. These newer frameworks are less mature than REST and XML/SOAP-based API frameworks, and introduce an entirely new attack surface.

The risk is magnified because many developers are using these frameworks for the first time, so they are more likely to make a mistake that could lead to a vulnerability. Adopting a baseline of governance standards and security tools is essential when adopting API protocols with structures even more flexible than REST APIs.

  • GraphQL: While GraphQL’s flexibility makes development easier, it can also introduce risk if developers and security teams aren’t aware of the framework’s nuances that can create gaps in an organisation’s cybersecurity.

    The majority of large data breaches result from malicious actors gaining access to sensitive databases and using the flexibility of the SQL language to exfiltrate data. For most organisations, internal-facing GraphQL APIs are a major blind spot to this attack vector as they provide the same query language flexibility as SQL, but lack specific detection and monitoring tools that are used to protect databases.

    Key security risks with a GraphQL API are broken object-level authorisation and excessive data exposure. If the API does not have a strong model for enforcing object-level authorisation, it’s possible to create sub-selections for related data that the client is not authorised to view.

    Organisations using GraphQL also have to be aware that they cannot simply limit requests to a database because of the additional functionalities it offers, which means defences are needed to protect against possible denial-of-service attacks that malicious actors could mount.
  • gRPC: The gRPC protocol, which also offers flexibility and performance improvements over REST, is another API framework that organisations are using to get mobile apps and connected systems to “talk” to each other. It, like GraphQL, is a relatively new framework that is usually not supported by traditional enterprise security inspection and protection controls which are effective with more traditional REST-based APIs.

    Organisations will usually need to re-invest in new security tooling and controls to ensure gRPC traffic and payloads are inspected and protected from all the typical types of application-injection-style threats and attacks.

    As before, securing data in transit is critical here, so it has to be inspected and protected. A misconfiguration or the careless storage of credentials in public-facing systems could expose the entire system. If developers do not take enough care in creating their code, mistakes can expose the apps and services.

Ongoing vigilance is order of the day

Ultimately, organisations have to stay ahead with APIs’ evolving risks and manage them by deploying the right development and security strategies.

As new API frameworks deliver new functionalities and open up new possibilities, organisations have to get acquainted with the risks involved. They need to be vigilant, always looking out for potential vulnerabilities buried in the added complexity or sometimes hidden in plain view.

Only in doing so can they safely deliver new user digital experiences that increasingly powerful APIs are making possible.