COMMENTARY
As organizations lean into low-code/no-code (LCNC) platforms to streamline development and empower citizen developers, security risks become increasingly challenging to manage. One of the more under-the-radar LCNC threats is OData injection, an attack vector that can expose sensitive corporate data and is predominant on the Microsoft Power Platform. This new vulnerability is poorly understood by security professionals in LCNC environments, where traditional safeguards are lacking.
What Is OData?
OData, or Open Data Protocol, is an OASIS standard that has gained traction in LCNC platforms as a way to manage and deliver data through REST APIs. It’s widely adopted because it allows seamless communication between applications and data sources, regardless of the underlying data storage model. In LCNC environments, it is commonly used as a query language to retrieve data from a variety of sources, such as SQL databases, SharePoint, or Dataverse.
OData is particularly valuable in LCNC platforms because of its simplicity — developers don’t need to be database experts to use it, and the same query language can be used for very different data sources.
The OData Injection Threat
OData injection manipulates user input that is later used by an application or automation to form an OData query. The query is then applied to an enterprise data source. This allows an attacker to gain unauthorized access to manipulate or exfiltrate sensitive user and corporate data.
While SQL injection (SQLi) is generally understood by security professionals, OData injection poses a different set of challenges, especially in LCNC environments, where multiple data sources are often connected and managed by citizen developers with minimal security training. Unlike SQLi, which is confined to relational databases, OData can connect to a wide array of data sources, including custom applications and third-party services, broadening the potential impact of an attack.
OData also lacks the well-established security practices that have been developed for SQL. For example, SQLi can typically be mitigated with parameterized queries, a practice that has become standard over the years. OData injection, however, doesn’t have a similar one-size-fits-all solution. Developers must create custom input validation mechanisms — a manual and error-prone process. In addition, the general lack of awareness of OData injection techniques further reduces the likelihood that custom validation methods will be implemented.
A New External Attack Surface
OData vulnerabilities in LCNC environments often stem from the unrecognized risks associated with external data inputs. These are frequently integrated into workflows that manipulate critical enterprise data, including Web forms, email messages, social media, and external Web applications. These inputs typically are accepted without stringent validation, leaving the attack surface vulnerable and often undefended, as developers and security teams may overlook these sources as potential risks.
This oversight allows attackers to exploit these inputs by injecting malicious OData queries. For instance, a simple product feedback form could be exploited to extract sensitive data or modify stored information.
Security Challenges
Because most citizen developers don’t have formal security training and are often unfamiliar with the dangers of accepting unchecked external inputs in their workflows, OData Injection vulnerabilities can flourish undetected.
Also, unlike SQL injection, validating user inputs in OData queries requires a more hands-on approach. Developers must manually sanitize inputs — removing harmful characters, ensuring proper formatting, and guarding against common injection techniques. This process takes time, effort, and more advanced programming knowledge that most LCNC developers lack.
Furthermore, in traditional development environments, security vulnerabilities are often tracked and remediated through ticketing systems or backlog management tools like Jira. This formal process does not exist in most LCNC development environments, where developers may not be full-time coders and have no formalized way to handle bug tracking or vulnerability management.
Mitigation Best Practices
Combating OData injection requires a proactive security strategy. Ideally, LCNC developers should be trained on OData query risks and how external inputs could be exploited. This is unrealistic, since citizen developers aren’t full-time coders.
Instead, automation can play a significant role in monitoring and detecting OData injection vulnerabilities. Security teams should deploy tools that continuously assess LCNC environments for potential vulnerabilities, especially as new applications and workflows are created. This will help identify weaknesses early and quickly provide developers with actionable insights into how to fix them.
Collaboration between security teams and LCNC developers is another essential piece of the puzzle. Security teams should be granted access to monitor the development process in real-time, particularly in environments where critical corporate data is being processed. When vulnerabilities are identified, security must communicate clearly with developers, offering specific guidance on how to remediate issues. This could include best practices for input validation and sanitation, as well as tools for automating the process where possible.
Lastly, security should be integrated into the LCNC development life cycle. Much like the “shift-left” movement in traditional software development, security checks should be built into the LCNC workflow from the outset. Automated testing tools can be leveraged to scan for vulnerabilities as applications are being built, reducing the likelihood of OData injection vulnerabilities slipping through the cracks.
As the adoption of LCNC continues to grow, so will the complexity of the threats organizations face. Addressing LCNC vulnerabilities like OData injection now will help keep enterprises safe in the long run.
