“Modernize” seems to be the most popular word to go alongside mainframes these days. We’re always being told to modernize our applications by migrating part or all of them to the cloud. We’re also being told that we can modernize our business-critical mainframe applications by using APIs (application programming interfaces) to expose mainframe-based data and assets.
Mainframe applications can be exposed as OpenAPI Specification-based APIs. They can then be connected to cloud-native application logic, mobile or web applications to maximize the use of your mainframe data and applications and include the power of modules running on other platforms, creating a new application that perfectly suits the needs of your customers on the platform of their choice. Using APIs also means that existing applications can be reused, accelerating the creation of these new super-applications—which is good for any business to be agile, innovative and able to use the channels that customers want.
You’ll also hear people talking about microservices, which are small, independent services that communicate over well-defined APIs. These services are combined to create larger applications.
The Bad News About APIs
The bad news is that APIs are now part of the attack surface available to hackers and add risk for any IT team. That’s because there are so many APIs in use now, so hackers are very familiar with the technology—and because APIs allow hackers to gain access to sensitive data, code and personal information such as social security, health data and bank records.
The problem for many mainframe sites is that non-IT people still view the mainframe as an island of technology separate from the rest of the IT world. They picture it as a castle with a moat around it and only a single entrance for people to enter and leave. Those people can be monitored, and everyone else (the bad actors) can be kept outside. Unfortunately, that is no longer the case, and it is certainly not a working model for modern security.
The expanding use of APIs effectively puts several doorways in our castle walls and drains the moat. Application development of APIs can use different protocols, and over time, newer protocols are used. That makes designing and testing a firewall that works effectively difficult. In addition, the traffic going to and from an API could be from another application, which makes the traffic look perfectly legitimate. So, it is challenging to identify an attack of any kind.
Top API Security Risks in 2023
With that in mind, let’s review the Open Worldwide Application Security Project (OWASP) top ten API security risks for 2023. I’m sharing the list to raise awareness of the risks that can be associated with the use of APIs:
API1:2023 – Broken Object Level Authorization – APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface of Object level access control issues. Object level authorization checks should be considered in every function that accesses a data source using an ID from the user.
API2:2023 – Broken Authentication – Authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws to assume other user's identities temporarily or permanently. Compromising a system's ability to identify the client/user, compromises API security overall.
API3:2023 – Broken Object Property Level Authorization – This category combines API3:2019 Excessive Data Exposure and API6:2019 – Mass Assignment, focusing on the root cause: the lack of or improper authorization validation at the object property level. This leads to information exposure or manipulation by unauthorized parties.
API4:2023 – Unrestricted Resource Consumption – Satisfying API requests requires resources such as network bandwidth, CPU, memory and storage. Other resources such as emails/SMS/phone calls or biometrics validation are made available by service providers via API integrations and paid for per request. Successful attacks can lead to denial of service or an increase of operational costs.
API5:2023 – Broken Function Level Authorization – Complex access control policies with different hierarchies, groups and roles—and an unclear separation between administrative and regular functions—tend to lead to authorization flaws. By exploiting these issues, attackers can gain access to other users’ resources and/or administrative functions.
API6:2023 -– Unrestricted Access to Sensitive Business Flows – APIs vulnerable to this risk expose a business flow— such as buying a ticket or posting a comment—without compensating for how the functionality could harm the business if used excessively in an automated manner. This doesn't necessarily come from implementation bugs.
API7:2023 – Server-Side Request Forgery – Server-Side Request Forgery (SSRF) flaws can occur when an API is fetching a remote resource without validating the user-supplied URI. This enables an attacker to coerce the application to send a crafted request to an unexpected destination, even when protected by a firewall or a VPN.
API8:2023 -– Security Misconfiguration – APIs and the systems supporting them typically contain complex configurations, meant to make the APIs more customizable. Software and DevOps engineers can miss these configurations, or don't follow security best practices when it comes to configuration, opening the door for different types of attacks.
API9:2023 – Improper Inventory Management – APIs tend to expose more endpoints than traditional web applications, making proper and updated documentation highly important. A proper inventory of hosts and deployed API versions also are important to mitigate issues such as deprecated API versions and exposed debug endpoints.
API10:2023 – Unsafe Consumption of APIs – Developers tend to trust data received from third-party APIs more than user input, and so tend to adopt weaker security standards. To compromise APIs, attackers go after integrated third-party services instead of trying to compromise the target API directly.
With the growing use of APIs and microservices, security should be top of mind for developers and the IT security team to ensure that bad actors can’t access one platform and use that as a route to access your mainframe and the large amounts of sensitive information stored on that platform.