APIs are essentially the digital middleman between financial institutions (like banks and credit unions) and the platforms (like Venmo and CashApp) that need to access user data. Similar to how retailers create personalized experiences by integrating location, inventory, and payment data, financial institutions also create contextual experiences for consumers and personnel by leveraging APIs.
The impact of APIs can be seen across facets of financial services, including brokerages, banks, neobanks, credit unions, credit lenders, and credit bureaus. APIs have also opened the door to emerging technologies like P2P payments and cryptocurrency exchanges. With the seamless connection between datasets, financial institutions are able to enhance the consumer experience and streamline payments. How exactly? APIs reduce the workload and redundant operations performed by developers by allowing them to access data stored elsewhere. This enables them to quickly execute on tasks and take on more important projects of greater impact.
APIs empower consumers to shop for the best rates and lowest fees when it comes to financial products. For example, when shopping for a vehicle, data is aggregated via APIs so car buyers can evaluate different lending options and select the best interest rate and terms. APIs also allow consumers to bank on the go. Even before the rise of the work from home era, consumers had high expectations of being able to access their financial information from their mobile devices. Now with the workforce under more flexible terms than ever before, APIs are enabling many of the localized services expats are seeing pop up globally.
One key to this level of interoperability within the financial services ecosystem is the concept of open banking. In a nutshell, open banking is the idea that traditional institutions expose their APIs for third party platforms to use in developing new services. This open sharing of data enables legacy entities to collaborate with emerging platforms versus compete with them. Well at least directly. Emerging fintech platforms do challenge existing institutions to improve their offerings and services – a desire that only makes the API landscape more rich.
Despite the myriad of benefits APIs present to the banking industry, APIs also expand the attack surface. And with the number of APIs skyrocketing, institutions are facing increasing challenges when it comes to security. The reality is, existing security tools can’t address this on their own. This calls for new API security solutions and best practices to identify and remediate vulnerabilities before they’re discovered by malicious actors. One of the most notable best practices involves API security testing.
As documented by the OWASP API Security Top 10, many of the most prevalent vulnerabilities and design flaws can be addressed with API security testing. The problem is, oftentimes, either there aren't enough security personnel who know how to test APIs, the number of APIs are growing faster than the security team can keep up with, or the existing security tools lack adequate coverage. Any one of these three scenarios can spell disaster for your environment. Additionally, another overlooked aspect that could also weaken your API security posture even if the aforementioned issues are addressed is the timing of API testing.
When it comes to API development, it’s not just a matter of testing for security gaps but also when you test your APIs. The traditional model places testing closer to the deployment phase. Although a vital step, testing only during this time is insufficient and can lead to serious vulnerabilities. How exactly? By consolidating testing into one phase of the software development lifecycle (SDLC), you create a bottleneck in the process as there is a never-ending supply of code to test.
To alleviate this bottleneck and expedite the process, corners may get cut and certain steps in this evaluation process may be incomplete or mistakenly bypassed altogether. As a result, code quality suffers and your API attack surface widens. And remember, this is the one phase in the process for testing - so anything missed here won’t be caught until it's too late.
Shift Left is an approach of moving a variety of tasks earlier in the development process. This means that tasks traditionally done at a later stage of the operation should instead be performed in earlier stages–particularly those related to API security and software testing.
(image: https://devopedia.org/images/article/121/8646.1538504518.png)
With security and testing baked into each step of the API development or DevOps process, a shift left approach ensures developers will be monitoring for vulnerabilities throughout the lifecycle. Shift left principles enable security teams to increase developer autonomy by providing support, expertise, and tooling while still delivering the required level of oversight. Developers can release more secure code at scale, build API security into the design, and make fixes early in the development process instead of scrambling to fix them later. Code testers are able to evaluate features as they are created and help ensure higher quality.
The shift left testing process is continuous, running parallel with development, and involves continuous communication between the clients, developers, and testers. The shift left testing process typically involves several steps:
The practice also helps minimize defects along the way by encouraging both Test-Driven Development (TDD) and Behavior-Driven Development (BDD).
As we just established, a shift left security approach moves testing to the left on the timeline, so the team performs tests earlier and more often in the life cycle. In contrast, a shift right approach considers testing in production with real users to be more useful.
(image: https://cdn.spark.app/media/launchable/image/shift_left_or_right_2.png)
The goals of shift right testing include:
Shift right testing ensures real world software stability and performance by testing in production environments, with scenarios that aren’t possible in the development environment, and improves user experience by collecting feedback and reviews from application users. Though this approach can improve some aspects of performance, it can leave you vulnerable since you won’t be able to catch misconfigurations and design flaws sooner.
Shift left testing saves time by identifying bugs earlier in the life cycle. More rigorous detection of errors and bottlenecks in advance enables testers to improve initial designs versus trying to remediate errors post production – which can be very time consuming. The shift left approach also ensures quality by allowing the development team to bake automation tools like API testing or unit testing right into the building process. Ultimately, apps, microservices, and APIs are more sufficiently protected. Waiting to test during production means the team is always playing catch up and facing inherently greater risk with potentially misconfigured APIs.
There are some basic things to keep in mind when implementing shift left security and testing.
Define goals. Since shift left demands organizational and cultural change, management should first define goals for the process to ensure any new tool or process introduced into the development cycle will work for the team’s existing development and testing methodologies.
Understand the supply chain. Know how and where your institution develops apps and software before architecting a comprehensive shift left security program. The security risk posture of the supply chain is largely dependent on the security proficiency of others in the chain. This also helps your developers identify small steps where testing might be placed earlier in the life cycle.
Automate security processes with security automation tools. Use continuous integration (CI) tools, issue tracking tools, and test automation tools to help teams establish and automate security practices during all stages of the life cycle.
Train development teams in coding securely and visible culture. Do not neglect the human aspects of risk during the move to shift left security. Constant visibility into application security should be part of the culture.
Shifting testing earlier in the development process offers a myriad of benefits for developers. These benefits can be summarized in two distinct outcomes: fixing vulnerabilities before production and innovating faster.
Address vulnerabilities before production
As discussed earlier in this document, testing APIs early and often shrinks the API attack surface and reduces the risk of successful attacks in production. Now you can minimize the potential for data leaks and manipulation of APIs without any modifications to production infrastructure. By finding and fixing issues earlier, not only can you remediate faster, but you also can lower remediation costs by up to 100x. This includes improving compliance, and avoiding regulatory fines and reputational damage from incidents.
Innovate Faster
By testing APIs early, you’re also able to improve security while increasing velocity. A shift left approach empowers you to eliminate the bottlenecks identified earlier. You can increase your institution’s confidence in APIs with continuous testing and reduce redundant pentesting and other third-party security testing costs. Ultimately, you are able to deliver secure code without having to become a security expert.
