3 Steps to Shielding Right While Shifting Left for API Protection

Most organizations have seen exponential growth in API usage in the last few years, driven by a rapid increase in mobile applications, containers, serverless computing, microservices architectures, and cloud adoption. However, APIs are a double-edged sword – bringing the benefits of rapid development and ease of integration to both the developer and the bad actor community. The speed that developers can now roll out new APIs can lead to coding errors, which eventually get exposed as vulnerabilities, as shown in the numerous API-related security incidents in the past year.

The adoption of APIs is often synonymous with a move towards a more iterative, DevOps-centric development methodology which can mean several things. In many cases, DevOps means decentralization of the development processes allowing teams to roll out their own APIs and apps. DevOps also entails development taking on added security responsibility, also known as shifting left. As I talk to customers about what shifting left and API security mean, they often struggle to articulate exactly what the end goal is.

The adoption of shift left has brought about improvements in tools and security protocols earlier in the application lifecycle. For example, most organizations working with the FDX API are adopting or have adopted a shift left methodology. However, developers are not security experts, with some expressing frustration with the amount of time spent on fixing code. Recent research shows that more than half (52%) of the developers surveyed said they would rather use this time to build new features and functionality, while 42% said freeing up this time would allow them to simply “do their job”. In the end, the speed with which development is moving has led to an increase in attacks on APIs resulting in security teams scrambling to protect them. A balance must be struck where adequate shield right protection mechanisms are in place to support a more secure shift left adoption.

Shield Right Step 1: Runtime Visibility

When asked, most organizations will offer only a guesstimate of “hundreds to thousands” of active APIs in their environment. Customer conversations combined with industry research support the notion that organizations have no idea what the accurate picture is. Neither the security team nor the DevOps team can protect what they do not know exists. The first step towards securing APIs is to create an inventory of all APIs in production: all the endpoints that exist, what APIs are they serving, and which team owns them.

Shield Right Step 2: Runtime Assessment

Security teams (and DevOps) can get overwhelmed if the inventory discovery uncovers many previously unknown APIs to protect. But not all APIs are created equal. Some APIs are informational, not posing any risk, while others may expose sensitive data – PII, PCI, or PHI. Some APIs may not even be properly authenticated, while others may be prone to business logic attacks like account takeovers or scraping. The way to avoid being overwhelmed is to prioritize the API inventory based on their risk exposure.

In parallel, the security team can work with the development teams to document all discovered APIs using a common, language-agnostic standard, like the OpenAPI Specification, or RAML. The same specification can then be used at runtime to detect deviations from the specification.

Shield Right Step 3: Runtime Protection

One other big realization as part of API security is that web security tools often fall short when it comes to API security. Most APIs are not vulnerable to the traditional cross-site scripting and SQL injection attacks. RESTful APIs are designed not to use session cookies and do not follow SQL syntax to access the backend database. Instead of JavaScript, they use JSON or XML. There is no room to inject JavaScript and execute it on remote endpoints and collect endpoint signals used to detect automated attacks. So, traditional WAFs or bot prevention tools are ineffective in protecting the (newly) inventoried APIs. The result is a false sense of security that the traditional web security tools will protect their APIs.

You need to implement runtime protections that can protect your APIs against the ever-changing, ever-maturing API attacks that bad actors execute. This requires based ML-technology that can determine the intent of the transactions (whether performed by bots or individuals) and then take quick action to block them or send them down another path. With this strong runtime protection is in place, only then can you start looking to the left to shore up security in your development pipeline.

Shifting Left While Shielding Right

Shift left adoption shows no signs of slowing down – the benefits are too great. A survey done by GitLab shows that roughly 25% of companies are in the DevOps “sweet spot” of three to five years of practice while another 37% are well on their way, with between one and three years of experience under their belts. Security teams continue to report that developers are not finding enough bugs at the earliest stages of development and are slow to prioritize fixing them. Over 42% said testing still happens too late in the life cycle, while 36% reported it was hard to understand, process, and fix any discovered vulnerabilities, and 31% found prioritizing vulnerability remediation an uphill battle.

In the context of this conversation, once all the APIs have been discovered and categorized, shift left means addressing security concerns earlier in the software development lifecycle – typically in the development phase, rather than after being rolled out to production. The later you find the problem, the more expensive it is to fix it. The entire process requires close collaboration between the security and development teams with a variety of tools available to assist in the process.

• Runtime Security: Runtime Security should be step 1 and as the name suggests, is about protecting APIs both known and unknown, modern or monolithic, no matter their location – data center, cloud, or Kubernetes. APIs are protected by inspecting API traffic at runtime. A good runtime API security tool needs to automatically create an inventory of all known and unknown endpoints. It helps you discover and prioritize, especially when you have a brand-new API Security program. It then provides a range of functions, including risk assessment, sensitive data exposure protection, business logic abuse protection, amongst others.
• Dynamic Application Security Testing (DAST): Once you have the runtime security covered, you can shift left by implementing a good DAST built specifically for APIs. DAST is a security testing method where you deploy a vulnerability scanner tool to actively probe a running application in a production or non-production environment. One of the key requirements for a DAST for APIs is that the tool needs to understand the APIs – which includes both syntactic and business logic it is exposing. A typical specification standard like OpenAPI Specification (formerly Swagger Specification) can help with the syntactic understanding of the API, but the business logic is much harder to understand.

• Static Application Security Testing (SAST): SAST is a method of detecting vulnerabilities by analyzing the source code. Having a common specification in place will help a SAST for APIs to detect common implementation issues in APIs like erroneously exposed APIs, parameters, error codes, and messages. These systems will integrate directly into API development environments like IDEs, bug tracking systems, and CI/CD tools.

Investing in an open standard like OpenAPI Specification as the contract will help collaborate between the development and security teams. The development team can then use this contract to build APIs. It will also act as a specification for the security tools to detect deviations between the implementation and enforce the contract at various stages from development to rollout. Having an OpenAPI Specification will allow you to shift left and catch things early.

Shifting left assumes you already have strong runtime protections to shield the right. Runtime API security measures are a must, as it is your last line of defense. DAST and SAST will bring value to API Security yet a recent Forrester report states that many organizations struggle to get more than 40% coverage with their SAST and DAST on their web applications. With such low coverage on the mature application development processes for web applications, full coverage for APIs will be a long ways off, further strengthening the argument for taking a shield right while shifting left methodology.