The DORA Regulation and API Security Testing

DORA, the Digital Operational Resilience Act, is an EU regulation for managing digital risks in finance.

It came into force on January 16, 2023. With January 17, 2025, being the deadline for implementing this regulation, financial organizations have a limited period of 24 months to meet the DORA security requirements. Noncompliance will lead to administrative and criminal penalties, as well as fines.

How does DORA affect APIs, if at all? And what does it have to do with API security testing? Read on, and you’ll discover.

An Overview of DORA

At its core, DORA provides an ICT (information and communications technology) risk management framework that consolidates security and resilience practices. It aims to help financial entities resist and respond to severe operational disruptions, such as cyberattacks and technology malfunctions, and restore their everyday work.

What Is the Legal Basis for DORA?

Article 114 of the Treaty on the Functioning of the European Union (TFEU) provides the legal basis for DORA. This article focuses on the approximation of laws and harmonization measures across the European Union.

Its influence shows in DORA’s seeking to coordinate ICT risk and incident management requirements across the European Union, elevate them to binding and precisely defined regulations, and ensure a unified approach to managing security threats and incidents.

In the same spirit of uniformity, the DORA Amending Directive aims to adjust existing European banking and finance regulations such as:

• AIFMD (Alternative Investment Fund Managers Directive)
• CRD (Capital Requirements Directive)
• MiFID (Markets in Financial Instruments Directive)
• PSD (Payment Services Directive)
• Solvency
• UCITS (Undertakings for the Collective Investment in Transferable Securities)

Who Does DORA Affect?

DORA is a regulation intended primarily for financial entities such as:

• Banks
• Investment companies
• Alternative investment fund managers
• Crypto asset providers
• Crowdfunding services
• Insurance enterprises and intermediaries

However, interestingly, DORA also addresses issues related to third-party ICTs like data centers, managed services, and cloud providers. Moreover, it extends to third-party information providers too, such as credit rating agencies and analytics services.

This regulation requires financial organizations to actively participate in managing risks from third-party ICT providers. Usually, regulators exclude third parties from financial entity requirements, which is clearly not the case with DORA. In that sense, it’s a unique and all-encompassing regulation.

Currently, DORA affects over 22,000 financial entities and ICT service providers across the EU.

What Does DORA Cover?

DORA covers the following five pillars of digital operational resilience:

• ICT risk management
• ICT incident management, classification, and reporting
• Digital operational resilience testing
• ICT third-party risk management
• Information sharing

The part that affects penetration testing and API security more closely is digital operational resilience testing.

DORA’s Digital Operational Resilience Testing

Digital operational resiliency testing is covered in Chapter IV of DORA’s regulation. This chapter consists of four articles, 24-27.

DORA, Article 24

Article 24 describes the general requirements for digital operational resilience testing. Simplified, the most significant points are the following:

• All financial entities but small businesses must have a digital operational resilience testing program.
• This program must include different tests, assessments, methodologies, practices, and tools.
• Testing can be carried out by both (independent) internal and external parties, with the caveat that financial entities ensure there’s no conflict of interest and allocate adequate resources for testing.
• All issues discovered during testing—bugs, flaws, and vulnerabilities—must be addressed (classified, prioritized, and remediated) methodically.
• Financial entities must test all ICT systems and apps supporting essential functions at least once a year.

DORA, Article 25

Article 25 builds upon the foundations laid down in DORA’s Article 24. It explicitly mentions security and software tests and assessments that the digital operational resilience testing program must incorporate. The list is long and includes the following:

Security testing

• Penetration testing
• Vulnerability assessment and scanning
• Network security assessment
• Gap analysis
• Source code review
• Physical security review
• Questionnaires and scanning software solutions

Software testing

• Scenario-based testing
• Compatibility testing
• Performance testing
• End-to-end testing

Both

• Open-source analysis

DORA, Article 26

Article 26 focuses on the need for advanced testing in the form of TLPT, that is, Threat-Led Penetration Testing.

TLPT is an enhanced penetration testing carried out by a red team. When attacking the target, the idea is to be utterly realistic and follow concrete threat actors’ TTPs (tactics, techniques, and procedures).

TLPT differs from regular penetration testing in coverage, complexity, and length. It tends to cover a much wider area of an organization’s attack surface, which makes it a complex and lengthy endeavor. While a regular pentest could take up to a few weeks, TLPT might last for months.

Article 26 requires financial entities to conduct a TLPT in production at least once in three years.

However, depending on the entity’s risk profile, the assigned authority may require it to conduct TLPT more or less frequently than that. No matter the frequency, each test must probe all or most of the financial entity’s critical functions.

It’s important to note that third-party ICT providers are not exempt from TLPTs. Another thing to note is that external testers are the only allowed type of TLPT testers for financial entities like credit companies.

DORA, Article 27

Article 27 is concerned exclusively with requirements regarding internal and external TLP testers, such as expertise, credentials, and contracting.

DORA and APIs

Although they’re not explicitly mentioned in DORA, APIs’ ubiquitous presence in modern information environments naturally leads us to infer this regulation’s relevance to API security.

With its connected and remotely controlled electric vehicles, the modern automotive industry would be hard to imagine without APIs.

Innovation in telecom, healthcare, and utilities? Inconceivable without APIs.

Open banking and fintech? Forget about them with no APIs around.

In short, application programming interfaces have become a digital pillar in today’s economic sectors and industries.

API Stats

Research supports this claim.

“The 2022 API Security Trends Report” revealed that:

• 15,564 is the average number of APIs enterprises use
• 25,592 is the average number of APIs enterprises with over 10,000 employees rely upon

The “2023 State of the API Report” states that:

• 121 million API collections have been created over time
• 1.29 billion API requests were created only in the past year (the period up to late May 2023)

“The API Security Disconnect” survey from 2023 reported that:

• 78% of surveyed organizations suffered an API incident during the last year
• 44% of organizations faced regulatory fines precisely due to API security incidents

APIs Rock but Can Be a Double-Edged Sword

APIs bring convenience to developers and end-users but can also make life easier for threat actors.

Instead of conducting complex and lengthy attacks that involve zero-days or social engineering, hackers can target low-hanging fruit such as improperly secured APIs to steal data and money or penetrate underlying systems. Exceptional expertise, highly sophisticated skills, and a long time are often not necessary for API exploitation, although targeted attacks can be sophisticated.

An example of the first possibility—stealing data—is the T-Mobile hack from the beginning of 2023. A threat actor gained access to the personal information of 37 million users through an insecure API.

This incident’s impact went much beyond data theft. It caused a loss of credibility and reputation damage—presumably along with a loss of customer goodwill and customers—especially considering that it was only one in a series of successful cyberattacks on the telecom colossus.

The Kronos Research attack, which also happened in 2023, is an example of the second possibility—stealing money. A hacker stole Ethereum worth $26 million from the crypto trading platform through exposed API keys.

The cyberattack on the Ukrainian power grid in 2022 is an example of the third possibility. The infamous hacker group Sandworm succeeded in causing a massive power outage through an obsolete API in an end-of-life version of a MicroSCADA control system.

That’s why API security testing is an indispensable force in securing any enterprise, especially financial entities, which have so much to lose. And that’s where the connection between DORA, with its digital operational resilience testing, and API security testing lies.

DORA and API Security Testing

DORA’s security testing requirements could prove vital for future API vulnerability and risk management development.

Virtually every new API security incident makes us realize that it could’ve been easily avoided—the emphasis is on easily—and that it wasn’t so much a consequence of hackers’ ingenuity as of overlooked API security best practices.

The obvious corollary is that we don’t need to move mountains to prevent these incidents. We only need to weave security into the API life cycle. And security testing is crucial to this aim.

API Security Testing in Development

Security is shifting left, meaning that security testing is becoming an integral part of API development. And that’s good.

Frequent security testing in SDLC (software development life cycle) reduces the possibility of security bugs, flaws, and vulnerabilities sneaking into production and live environments. In the long run, this proactive approach translates into lower remediation costs, higher efficiency, and a more robust API security posture.

However, shift-left security doesn’t imply only integrating API security testing into SDLC. It also means automating it, that is, including it in the CI/CD pipeline. Manual testing has undeniable merits, but due to its high costs in both time and money, it has to be reserved only for situations requiring it.

Besides, there are already well-built automated API security solutions specialized in continuous testing. There’s no reason not to take advantage of the convenience and benefits they bring.

Also, taking advantage of existing purpose-built API security solutions perfectly fits into the DORA framework, which requires the use of a wide range of tools to ensure the digital operational resilience of financial entities.

API Testing in Production

Adopting shift-left security testing doesn’t mean you don’t need security testing in production. These two complement each other and are necessary to secure your APIs.

It is imperative to scan APIs at regular intervals to discover missed vulnerabilities, misconfigurations, and business logic flaws in production before threat actors find them. Authoritative guidelines like the OWASP Top 10 API Security Risks and the HackerOne Top 10 Vulnerability Types can be of tremendous help.

In addition, regular and frequent API penetration testing—not to be confused with TLPT—can be a game changer in securing your APIs. Most API vulnerabilities in the wild are discovered by penetration testers and ethical hackers, so carrying out regular penetration tests, especially automated penetration tests, adds much efficiency to your API security endeavors.

Typically, a good API security testing solution comes with a reporting system to provide proof of your compliance efforts in black and white. In addition, it should include remediation guidance for the vulnerabilities found during testing, so you’re not left in the lurch—having the knowledge of what’s wrong but not knowing how to fix it.

Final Thoughts

DORA is a new EU regulation concerning ICT risk management and digital operational resilience that financial entities must implement by January 2025. It doesn’t mention APIs, but since APIs are everywhere in today’s finance industry, DORA absolutely applies to APIs.

On the one hand, new compliance requirements like this put additional pressure on security and development teams. On the other hand, knowing DORA’s objective, we cannot help but think that this regulation offers an almost historical opportunity to elevate and consolidate API security in finance across the entire EU.

By regularly and frequently testing APIs in both development and production, financial entities can meet DORA’s requirements for digital operational resilience testing and take big steps toward compliance.

Download the DORA checklist to learn further details about how to comply with this regulation.

Carlo De Micheli

Director of Product Marketing

Carlo is a versatile professional with extensive international experience. His enthusiasm for innovation extends across cybersecurity, automotive, and aerospace, where he actively engages in pioneering projects. Holding a technical background in aerospace engineering and supplementing it with independent studies in programming and security, Carlo has organized and presented at international conferences and established tech startups related to the sharing economy and fashion before embracing marketing and sales.

Zoran Gorgiev

Technical Content Specialist

Zoran is a technical content specialist with SEO mastery and practical cybersecurity and web technologies knowledge. He has rich international experience in content and product marketing, helping both small companies and large corporations implement effective content strategies and attain their marketing objectives. He applies his philosophical background to his writing to create intellectually stimulating content. Zoran is an avid learner who believes in continuous learning and never-ending skill polishing.