Shield Right While Shifting Left to Eliminate FDX API Security Gaps at Runtime

As a member of the FDX (Financial Data Exchange) working group, I recently participated in a panel discussion at the FDX Spring Summit. The topic was how you should shield right as you shift left to protect data transmitted across the FDX API. To add more context to the discussion, FDX is inherently designed with security in mind. Most organizations working with the FDX API are adopting or have adopted a shift left methodology where security is integrated into the development process. We would all agree that DevOps security enables the delivery of more secure APIs, but it should be considered complementary to, not a replacement for runtime API protection.

Ok. That’s a bit of a mouthful. Let’s first start with some definitions. As defined above, shift left means early detection and remediation of errors that might lead to a security incident. Shield right may not be clear to all – it’s the last line of defense and is intended to protect against unknown attacks. Even a perfectly coded app or API is susceptible to an automated attack or business logic abuse.

Many will look at FDX as an evolution of OFX, and in many ways, it is. OFX was initially designed to tie consumer-oriented financial apps (e.g., Microsoft Money, Intuit QuickBooks) to the user’s financial institutions. FDX is geared towards connecting financial aggregators, primarily SaaS services (e.g., Mint, Yodlee), with the user’s respective institutions and allowing them to share a significantly greater amount of information. And while FDX is designed with security in mind, the member apps being developed will need to consider the end user, a group that has shown to be less security conscious than we would like. During the panelist discussion, we focused on three recommendations for the FDX member community.

Can You Identify All Your APIs to Understand Your API Footprint?

Based on customer feedback, and industry research, most organizations cannot identify all of their APIs. Many reasons really – distributed development, legacy APIs, mergers and acquisitions, the list goes on. The challenge here is that you cannot protect what you cannot see. While FDX has a detailed specification that your team is using, you may not know where the endpoints are, which ones are accessing assets of value or which group owns the API in the event updates need to be made. Finally, where and how they are exposed to the public are key to understanding the exposure and, in turn, how best to protect the API.

✓ Recommendation: As part of your (new or existing) API governance process, keep an up-to-date inventory of your APIs, internal and external.

Does Shift Left Improve Security, and Can it Help You Assess Your Exposure?

We would all agree that an added focus on security during the API life cycle is a good thing, so yes, shift left does improve security. But a perfectly secure API is still susceptible to an automated attack or business logic abuse, so shield right is still needed. It’s also important to note that traditional app coding is a bit different than API coding. APIs are stateless in nature and include the entire transaction, making it (more) critical for developers to understand, beyond the spec, exactly what the user interaction and outcome is. Secure API coding practices dictate that developers use minimal API responses; only expose the parameter values/headers needed; ensure strong authentication/access control is enabled; and, use strong encryption.

✓ Recommendation: Proactive actions in development, testing and production phases that confirm secure coding best practices can eliminate future incidents.

Is Your FDX API Jeopardizing Compliance?

FDX API is designed to share financial information with consumers and financial aggregators. If this API is not protected well, it does introduce compliance issues. FDX API specification does a great job of documenting all the endpoints and the data they are supposed to expose. Making sure that every endpoint is only exposing information that is agreed upon in the FDX specification and nothing more is extremely important. Developers can make mistakes and can lead to unintended exposure of personal and financial information. On top of that, there needs to be proper authentication, authorization and observability for every API endpoint.

✓ Recommendation:  Uncovering unintended data exposure during the development and testing combined with continuous runtime API visibility can significantly reduce the risk of being out of compliance.

Shield Right & Shift Left: Together

All panelists agreed that as FDX is a brand-new API being developed from scratch, there is an opportunity to shift left and adopt security processes early in the development and testing phases. But shift left assumes that we’re already covering the right with proper observability and protection of APIs at runtime. It’s not one or the other. It’s both – the two methodologies are complementary.