This week, we take a look at Vodafone’s journey to API Governance with both challenges and benefits. We review news about the latest patch updates to the OpenAPI specification, and tips for API prototyping using OpenAPI description files. We also have multiple incidents of APIs with OWASP vulnerabilities like broken authentication and security misconfiguration.
Article: Vodafone’s journey to API Governance
First, Dimitris Maimaris shares Vodafone’s experience in adopting an API-first approach to API development and creating an effective program for API governance.
Vodafone’s API team consists of 100 developers and QA engineers, supported by 16 solution architects, managing a growing ecosystem of over 250 APIs. As the number of APIs grew, the team sought to adopt standardized policies and practices to govern how APIs are developed, deployed and used.
Standardizing practices across the API lifecycle creates consistency in how team members operate, as well as consistency in how API security policies are reliably enforced across all APIs. Vodafone reports benefits in terms of improved API integration, reduced redundancy and enhanced reusability, as well as reduced dependency between front-end and back-end teams to accelerate API development and service delivery.
Recommended reading for API teams.
Article: Create API prototypes using OpenAPI
OpenAPI provides a formal, widely accepted format for describing an API. You can use it to define the paths and operations that an API supports, the headers and parameters that it requires or accepts, and the schemas of the data that are passed in request and response messages. You can also use OpenAPI to define the authentication or authorization information that an API requires.
So, an OpenAPI description can provide a complete and detailed design of the expected behavior of an API. However, sometimes it is necessary to test something to get a real idea of how it works. So how do we quickly and easily convert an API design from a static OpenAPI document into something functional that we can test?
In his recent article, Bruno Pedro explains how he achieved this by building his own API prototyping solution from a selection of useful VSCode extensions. With this tool, he is able to simulate an API server and generate a useful API client, both by leveraging the OpenAPI description of the API.
According to the OpenAPI initiative, an API description file should “strive to be as complete and fully-detailed as possible…the more unambiguous it is, the more useful it becomes”.
This is certainly true when it comes to automatically generating mock API clients and responses, as a detailed and complete API description will help create a more realistic API simulation. Therefore, auditing an OpenAPI file for correctness and completeness is an important step in creating useful API prototypes.
Great article by Bruno Pedro, a must read.
Industry News: OpenAPI releases 3.0.4 and 3.1.1
New updates to the OpenAPI specification have been released for versions 3.0 and 3.1.
According to the release notes, there are no changes to the requirements in the 3.0.4 or 3.1.1 patch releases. Instead, the updates focus on improving the text of the specification, with clarifications and additional examples provided for a number of sections.
Information has been added to better explain data types and query parameters. There is now a separate section describing headers. Additionally, more examples have been added in 3.0.4 and 3.1.1, which really help illustrate and clarify some of the text.
If your team is currently using older versions of 3.0 or 3.1, you should consider updating your documentation links to point to these newer versions.
Also check out this video of Erik Wilde interviewing OAI Technical Steering Committee member Lorna Mitchell about these latest patch releases, as well as a status update on versions 3.2 and 4.0 (aka “moonwalk”).
Breach: Fortinet devices exposed by broken API authentication
FortiGate network firewalls can be exploited via a vulnerable API in FortiManager, a network management platform used to centrally control multiple firewall deployments.
According to a report, the API implements the FortiGate to FortiManager (FGFM) protocol. A security bug in the API allows commands to be sent to networked devices without any authorization. This allows attackers to remotely take control of the FortiManager device and connected FortiGate firewall devices within vulnerable enterprise networks.
Network devices now commonly offer APIs to facilitate integration with other devices and services, as well as provisioning or configuring device settings. We have previously reported API vulnerabilities found in Cisco and Trend Micro network devices that also allow an attacker to access and compromise other connected devices.
This is a reminder that APIs are frequently deployed with critical security vulnerabilities, whether these APIs are used in web applications, mobile applications, or critical network devices, and must be thoroughly tested to uncover such vulnerabilities.
Vulnerability: Multiple OWASP Vulnerabilities found in Cyberpanel
Cyberpanel is a free, open-source web hosting control panel. A researcher has discovered two API vulnerabilities that together expose the platform to command injection attacks.
In the case of the first vulnerability, the API was developed to enforce authentication separately on each individual API route, and in some cases, developers forgot to enforce the necessary authentication. For the second vulnerability, the API was developed to explicitly handle HTTP POST requests, but also accepted and handled other HTTP verbs such as PUT and PATCH by default, causing unexpected execution paths in the API code.
For security reasons, it is strongly recommended to apply authorization on an API level rather than at the individual route or operation level. This ensures that authorization is applied as the default behavior for all new routes or paths added to an API. On the other hand, applying authorization on each individual route is an error-prone approach, as it is easy for developers to forget to include essential security checks when adding a new route or operation to an API. This appears to have happened repeatedly with the Cyberpanel API. Adopting best practices could help reduce the risk of the same security bug recurring.
For the second issue, the OWASP Top 10 API security guidelines recommend explicitly disabling unnecessary features, including HTTP verbs, to avoid security misconfiguration vulnerabilities in APIs. This means that an API should only accept and process HTTP verbs that are expected for an operation. For any other verbs received, the API should respond with an HTTP 405 “Method Not Allowed” response.
The detailed research to uncover vulnerabilities in this case provides an opportunity to address root causes, implement best practices, and prevent future security incidents.
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
