This week, we focus on secure API design and best practices. We examine Cloudflare’s latest measures to prevent API token exposure, analyze three recent API vulnerabilities affecting an AI platform, a WordPress plugin, and a popular LMS solution, and highlight key articles on DevSecOps and API security best practices.
Article: How HTTPS redirects can expose API data
In a March blog post, Cloudflare announced it will block all API requests made over unsecured HTTP at the network level, ensuring that all client connections use encrypted HTTPS.
Some API servers enforce HTTPS by redirecting HTTP requests to secure endpoints, this method still exposes sensitive data such as API keys or access tokens to potential man-in-the-middle attacks during the initial unencrypted request.
Source: Cloudflare
Despite the widespread adoption of HTTPS, some web applications and APIs remain exposed to data leaks over unsecured HTTP connections. For example, research by automotive cybersecurity firm VicOne uncovered companies across the US, Europe, and Asia transmitting cleartext passwords from vehicle tracking systems over non-HTTPS connections, leaving sensitive data vulnerable to interception.
Disabling HTTP ports eliminates this risk, by ensuring that any attempt to connect over HTTP is blocked at the network level, before application-layer data or tokens can be exchanged.
If your server applications currently rely on HTTP-to-HTTPS redirects, it might be worth considering disabling HTTP ports altogether, to prevent exposure of sensitive API traffic.
Vulnerability: AI platform adds input validation to secure APIs
Flowise is a popular open-source platform for creating AI agents and orchestrating LLM flows. A researcher recently uncovered an API flaw that allowed unauthenticated users to upload or overwrite arbitrary files on the platform.
The researcher shared a detailed analysis of the API vulnerability. The API allows users to upload files to the platform. The request includes two user-supplied path parameters values. Those path parameters were later used in the code to construct a filepath to the location on the server where the file is stored.
But the parameter values were not checked and validated by the API. This gives room for a malicious user to set malicious values, and when it comes to file uploads the path traversal pattern is a common tactic used to access unauthorized files and locations on a server.
In this case the API vulnerability allowed a user to overwrite critical files on the server at unauthorized locations on the file system. Flowise have since fixed the API flaw to remove the vulnerability by adding proper input validation in the API code, ensuring the vulnerable user-supplied parameters can only be the expected UUID format.
Teams can mitigate common API vulnerabilities by integrating robust input validation at the initial design and implementation phases for API development. This proactive approach helps eliminate weaknesses that attackers frequently exploit.
Article: The benefits of starting with an OpenAPI description
In a blog post on APIsYouWontHate.com, Phil Sturgeon makes a strong case for API first design. The post compares and contrasts the code-first and design-first workflows for API development, and describes some of the negative implications of rushing to the coding step as fast as possible.
One of the main pushbacks we hear from teams who are considering a design-first approach is all the extra time teams must invest in carefully preparing a detailed OpenAPI contract with enough specificity to clearly describe an API’s design intent.
However, as noted in his post, Sturgeon argues that this upfront investment during the early design phase reaps significant time savings throughout the rest of the API’s lifecycle.
There is a long list of additional benefits to teams who adopt a design-first approach, such as leveraging the OpenAPI contract to automate functional and vulnerability tests, API code or mock services. Standardizing the API documentation quality also helps to reduce inefficiencies and improves the experience for API consumers to use and integrate an API.
If you’re still on the fence about moving to design-first in your API team, this article must just tip the balance!
Vulnerability: Data whitelisting and API injection attacks
A researcher recently uncovered an API vulnerability in a WordPress plugin that exposed WordPress sites to SQL injection attacks against the site database.
The researcher shared an account of discovering the vulnerability in the plugin source code, where HTTP request parameters were passed unsafely to an SQL query.
It’s worth noting that the API design allows users to select database table names. This is inherently insecure, as highlighted in the OWASP SQL Prevention Cheat Sheet:
“WARNING: Using user parameter values to target table or column names is a symptom of poor design and a full rewrite should be considered if time allows.”
The solution applied in this case was to enforce whitelist validation on the vulnerable parameters, so that only valid table names would be accepted by the API and malicious queries rejected by default. This helps to reduce the risk of vulnerability exploitation, but doesn’t remove the underlying vulnerability in the code.
Using prepared statements or properly constructed stored procedures is the recommended way to safely handle user supplied data in database queries, though whitelisting and input validation also offers a defense-in-depth approach to secure APIs against injection attacks.
Article: DevSecOps with API Security by Design
With the rise of frameworks, automation, and AI-powered tools, developers can now build and deploy APIs in a matter of hours, days at most. In teams following DevOps practices, developers often have full autonomy to deploy their own APIs with little to no oversight or security checks.
This rapid delivery model is great for meeting the ever-increasing demand for API-based applications and integrations. However, in software development, speed often comes at the cost of security. The result is APIs going live with critical vulnerabilities, exposing organizations to data breaches, remediation headaches, and compliance risks.
A recent DZone article highlights practical approaches to tackling these security challenges by embedding security into the early stages of API design, bringing the ‘Sec’ into DevSecOps. The article advocates for integrating threat modeling as a key design step, alongside reviewing API contracts and incorporating static analysis into the build pipeline.
These insights underscore the importance of shifting security left in the API development lifecycle. By proactively identifying risks before implementation, teams can significantly reduce security flaws while maintaining development velocity.
Vulnerability: Check the API Error Response for Leakage
This week I came across a security announcement for the Moodle LMS platform reporting an API vulnerability. According to the announcement one of the APIs on the platform was leaking user data in the API’s error response. A user did not need to be authenticated on the platform to view the leaked data of other users.
The exposed user data included the user’s name, e-mail address, hashed password, last login IP, and some metadata. The term “some metadata” could of course mean many things, though leaking email addresses and hashed passwords is already a serious problem.
A similar vulnerability made headlines last year involving a vulnerable API from the social media company Spoutible. We covered that case in an earlier newsletter. In that incident similar user data was exposed in the API response, including hashed passwords and also codes and secrets for two-factor authentication.
API security often focuses on protecting against malicious data on the inbound request. However as this case and previous cases highlight, API security must also include filtering data in the outbound request, to ensure all data returned in the API response is expected, valid and authorized.
Schema validation on both the request and response payloads, including error response messages, can help to prevent painful data exposures from APIs.
Article: API Design Matters for Security
Finally this week, we highlight a recent post by David Biesack from APIDesignMatters on best practices for structuring query parameters in Web APIs.
David describes using query parameters to “parameterize queries”, by filtering API responses to return only relevant resources. He breaks down multiple design patterns for structuring query strings, whether handling single values, field-value pairs, or data ranges, offering practical guidance for API standardization.
The post also shares an example of defining query parameters formally using the OpenAPI Specification. Well-documented query structures not only improve consistency but also enable automated security testing. Attackers frequently exploit query parameters for injection attacks and business logic abuses, making strict design patterns a crucial defense.
By adopting consistent query conventions and enforcing valid input constraints, developers can make APIs more secure by design, another strong argument for why API design matters!
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
