How to Build a Secure API Strategy for the API Economy

An API is one way that businesses can increase the value of their offerings for customers. APIs, especially through B2B partnerships and B2C applications, can increase a company’s reach and make digital assets and services available to broader audiences. This sharing of resources has given rise to the "API economy,” in which companies create products and businesses with APIs as their focus. However, as this space grows and the number of players increase, so too are the number of dangers posed by the adoption of insecure APIs in the enterprise. Hence, businesses need a strategy for building and operating secure APIs.

For example, in October 2017, T-Mobile had to address an API vulnerability that hackers used to gain personal information. They were able to change the phone number value in the API call and exfiltrate all the information associated with that phone number. Through this door, the hackers stole email addresses, device ID numbers, and account details.

The dangers of insecure APIs

According to Gartner, an average enterprise will use more APIs than it provides. In most enterprises, APIs are used across departments, often without the direct knowledge and approval of senior management or the CIO. In a rush to monetize services and make APIs easily available, many businesses forgo proper security measures.

Remember, as Gartner says, APIs are doors into your data and applications, so pausing to include security is just as important as securing web applications.

For example, APIs could expose a company’s transactional systems to the outside world in unprecedented ways. Systems of record are not intended to be available publicly. As such, development teams must test, test, and retest APIs stringently before release.

Once developers embed an unsecured API into an enterprise's applications, it can infiltrate and reduce that organization’s overall security posture. Some enterprises have hundreds of consumer-facing web applications, and each of those websites could have anywhere from five to 32 vulnerabilities — that’s a staggering risk of exposure.

Sometimes, developers mistake the capabilities of API management tools and expect them to solve all API security challenges. API management tools do provide security policies that work at the perimeter, but not all of them play a role in securing the business logic that serves up the API. For this, developers need to treat APIs as yet another form factor for their applications and ensure that adequate attention is paid to securing them.

To secure APIs completely, addressing the needs of security in architecture, DevOps, and production is critical. The inflection points for security assessment in the software development life cycle (SDLC) may vary depending on whether the development team is enabling APIs for legacy applications or building new API-first applications.

While the assessment and remediation requirements will mostly remain the same, the team needs to:

  • Use secure design patterns within the enterprise application architecture
  • Perform Source Code analysis or the automated testing of source code to debug an application before it's distributed or sold
  • Discover and train APIs for dynamic scanning, and create a plan for remediation/mitigating discovered vulnerabilities
  • Implement a robust feedback loop within the SDLC to act on the findings of various scans

These steps ensure that APIs have full security coverage, and teams can find and fix vulnerabilities before problems arise.

Enterprise application architecture

When developers turn to a microservices-based architecture to speed up a project, they should leverage an application architecture that enforces secure design patterns, ensuring that all source code is inheriting security best practices through the required implementing of a known-secure architecture.  A few examples of secure design patterns are:


To build secure APIs and speed the creation of API-based applications, make sure developers are part of a DevSecOps program so they can prepare these projects for adoption across the enterprise and with external partners. Taking a phased approach to implement DevSecOps yields the best results without affecting an application’s time to market. Here is one such approach (comprising of the three phases):

1) Risk discovery and management  

In the first phase, the team focuses on discovering exploitable risks in the APIs in their current released state. The risks they find here will contribute to the APIs top line risk metrics. These vulnerabilities will also form the basis of a comparison and analysis of data for planning and prioritizing remediation initiatives.

2) Release assurance

In this phase, developers ensure that a new release candidate API does not add additional risk as compared to the application’s current release. The release assurance phase is an ideal place for the team to integrate portions of the assessment methodology into the release pipeline. Developers will  have the most success when they combine a pre-existing and robust risk discovery program.

3) Developer Enablement

Finally, the organization aims to reduce the number of vulnerabilities developers are introducing into the release pipeline by bringing assessment and education into its workspace. The enterprise provides to the team lightweight application security tools that they can run in their development Sandbox to eliminate security issues before these are committed to version control or the release pipeline. Developers also receive education on the common findings of the risk discovery and release assurance, so they can develop secure enterprise libraries to replace commonly used components that are prone to misuse, and they establish a question and answer feedback loop via integrated security knowledge bases or direct interaction with application security experts.

With a phased approach to DevSecOps implementation, a development team can speed the discovery and resolution of application security vulnerabilities using shorter “sprints” in the development process, adding this technique to the 24x7x365 application scanning and monitoring functions. This is critical in identifying and remediating application security vulnerabilities early in the development process, which reduces the window of exposure when the API is released to production. 

Making the adoption of API security testing easy

Performing a source code assessment, software composition analysis, and a dynamic assessment of API-first applications in an “as-a-service” manner is very important. Using these security assessments provides accurate results, making the feedback loop meaningful in a secure application development process. Finally, developers should integrate the security assessments into the software lifecycle, so that security feedback becomes part of development sprint cycles. The bottom line is that the results of the security assessments become mission critical to development and security stakeholders within the sprint cycle, and these techniques can increase the integrity of a company’s APIs.

Be sure to read the next Security article: Data Theorem Announces New Solutions for API Security Analysis