Hardening API Controls

The API Threat Landscape

Application Programming Interfaces (APIs) are protocols that enable software applications to exchange data with each other. APIs have become a critical piece of financial firms’ cyber infrastructure[i] because they enable firms to move data  – some of it very sensitive, like customers’ personally identifiable information (PII) – between computer systems. The use of APIs is growing because many business operations and customer services, such as those essential to open banking,[ii] rely on the use of APIs.

However, APIs’ vital role in financial services operations, the sector’s broad use of APIs, and the high-value data they transmit make them an attractive target to threat actors. DDoS attacks on APIs alone rose 58% last year, as described in From Nuisance to Strategic Threat: DDoS Attacks Against the Financial Sector, which we co-wrote with founding Critical Provider, Akamai. Meanwhile, artificial intelligence provides even low-skill cybercriminals with sophisticated tools to launch precision attacks on APIs.

API Breach Data

• 46% of all account takeover attacks are aimed at API endpoints. The State of API Security in 2024, Imperva, a Thales company
• An API breach leaks 10X more data, on average, than other types of security breach. Gartner Research Market Guide for API Protection
• The average cost to remediate an API breach in the US was $591,404 in 2024. 2024 API Security Impact Study, Akamai

Data from Akamai’s recent report, State of Apps and API Security 2025: How AI Is Shifting the Digital Terrain is included in the table below to illustrate the number of security alerts related to API attacks in 2025 as they pertain to various security frameworks and compliance standards. 

This threat landscape requires a tactical approach to hardening API controls. We recommend approaching it this way:

1. Define operational challenges
2. Test the Proof of Concept
3. Plan remediation and risk reduction

This approach was drafted by FS-ISAC cybersecurity experts and is informed by FS-ISAC’s threat intelligence. This report describes the process in detail for practitioners and cybersecurity professionals in financial services firms. We use it to harden FS-ISAC’s API controls and encourage other firms to adopt it as well. 

1. Define Operational Challenges

The first step is an audit to determine the operational challenges the firm faces. Catalog everything – public, private, and  third-party — and assess your security posture by reviewing authentication, authorization, encryption, rate limiting, logging, etc. Pay particular attention to visibility issues around the health and data processed by APIs –threat actors are known to look for API responses containing PII, account details, or internal IDs.

Then, consider stakeholder alignment – particularly DevOps, security, engineering, and product teams – to define pain points across the API lifecycle.

Finally, understand the standards (e.g., OWASP API Top 10,  PCI-DSS,  FFIEC ) that apply and the threats that are most relevant to your institution and threat environment.

The audit will provide the focus areas for the next step: a Proof of Concept (PoC) test. 

The audit may consider: 

• SQL injections
• Exposed secrets
• Unmanaged APIs
• Inconsistent data filtering across endpoints and misconfigured endpoints
• Poor version control
• Broken authentication or authorization that could allow attackers to impersonate users or access unauthorized resources
• Outdated or unpatched dependencies on third-party libraries

2. Proof of Concept Testing

Proof of Concept (PoC) tests measure cybersecurity solutions against a threat – actual or theoretical – in a real-world environment and gauge the solution’s compatibility with the firm’s systems in its threat landscape. The objective of a PoC around hardening API controls is to validate the tools, methods, or configurations you may use before implementing them.

The following validations are typical for this kind of PoC.

3. Risk and Risk-Reduction Plan

The PoC will indicate subsequent control deployment, which will influence the cybersecurity team’s priorities for securing APIs and reducing long-term exposure.

Broadly, these plans should include:

• A risk register – ranked critical, high, medium, and low – based on the PoC findings and the firm’s operational challenges.
• A remediation plan with short-term fixes (like rate limiting), long-term improvements (e.g., full API gateway implementation, least privilege redesign), and ongoing monitoring.
• A set of standards for API development, testing, and deployment.

Conclusion

Last year, FS-ISAC published our Cyber Fundamentals detailing 15 crucial principles for financial services firms. The last fundamental on the list is “hardening API controls.”

While API controls are last on the list, safeguarding them is a top priority. All financial services institutions, no matter how cyber-mature, face the possibility of an attack on their APIs– if only because their third-party suppliers do.

This tactical, three-phase approach – defining operational challenges, testing a PoC, and drafting a remediation plan – will help streamline what can be a big job. We also encourage leveraging a cybersecurity information-sharing network like ours for real-time intel on emerging API threats.