APIs are incredibly powerful. They offer a way for systems to talk with one another, opening a world of collaborative, cross-functional solutions. These systems are also incredibly ubiquitous, with even the most innocuous day-to-day systems being driven by complex interactions under glossy interfaces.

With great power can come great risk, however. With APIs, one of the most common risks lies in misconfiguration. But what really is misconfiguration, and how widespread is the problem?

Below, we’re going to look at misconfigurations in the API space and contextualize the problem. We’ll look at one example of what this kind of issue can look like at scale and extract best practices to ensure your systems are secure.

What Is Misconfiguration?

API misconfiguration is a general term that refers to the improper or incomplete setup of systems in an API’s design or deployment process. This can take a lot of different forms, but more often than not, they are simple mistakes such as incomplete authentication schemes or excessive data exposure.

These misconfigurations can result in a critical vulnerability to attacks, increasing the surface area of an API and reducing the efficacy of security postures. Misconfigurations can happen at many different points in the API lifecycle and, in many cases, are entirely unintentional rather than intentional or malicious.

7 Types of API Misconfigurations

Misconfiguration can appear at any point in the API development lifecycle. Here is a handful of common categories.

1. Excessive Data Exposure

When an API is too verbose or sends too much information in response to a request, the system engages in excessive data exposure. This often occurs because of oversights on how endpoints interact with each other or how requests are limited. These types of misconfigurations can result in exposing private data or escalations to attacks in other areas.

2. Insufficient Data Controls

Rate limiting and throttling is meant to control the amount of data in transit in a network by limiting the total number or volume of requests at scale. When these systems are misconfigured, a system can be exposed to critical data issues and memory overflow concerns.

3. Insufficient or Lacking Authentication and Authorization

Authentication (making sure someone is who they say they are) and authorization (making sure someone is allowed to do what they’re trying to do) are critical elements of a security posture. When they are improperly configured, this can result in users being able to access data they shouldn’t, self-escalation of rights, and much more.

4. Insecure Endpoints

Endpoints that are exposed that should not be can result in critical backend vulnerabilities, such as exposing admin panels, data reporting, and other controls. Similarly, pagination on endpoints that should not have them can allow unintended data verbosity, allowing for scraping or data exposure.

5. Improper CORS Configuration

Cross-origin resource sharing (CORS) misconfigurations might allow untrusted domains to access APIs or resources, exposing private data and even enabling cross-site script, or XSS, attacks.

6. Insufficient Logging and Monitoring

Poor logging and monitoring can result in difficulties detecting and responding to data breaches, unallowed access, sensitive information exfiltration, and more.

7. Poor Encryption

Poor or lacking encryption at rest and in transit can make APIs vulnerable to data capture, replay, or man-in-the-middle attacks, bypassing security entirely and allowing for the exfiltration of private data in the case of a storage breach.

Misconfiguration Risks

Misconfiguration is a dangerous issue with serious potential for damage to the organization, its APIs and endpoints, and its user base. When APIs are misconfigured, it’s easier for data to be breached and more difficult for those breaches to be discovered. Misconfigurations are like putting a door in a frame but removing the locking mechanism — it’s a false sense of security.

Unauthorized access can be as benign as allowing someone to access hidden resources or as worrying as allowing a user to make themselves an admin. Improper configuration can also degrade controls on the network, allowing for attacks on the infrastructure and systems underpinning it. This can lead to denial of service, affecting both the organization’s revenue and the utility for its user base.

Then, there is the impact on reputation and regulatory compliance. Misconfigurations often require minimal attention to fix, and getting this wrong can result in others viewing your organization as less than professional at best or purposefully negligent at worst. Furthermore, GDPR, CPRA, and other privacy regulations have serious legal and financial punishments for data exposure, whether intentional or not. Misconfiguration can have serious economic impacts, in some cases over millions.

A Case Study: The Microsoft Power Pages Data Exposure

In November of 2024, a report was released by Aaron Costello, Chief of SaaS Security Resaerch at AppOmni. The report detailed a very real example of what misconfiguration can do at scale — a compelling case study of how a minor issue can balloon rather quickly.

The crux of the issue seems straightforward. In Microsoft Power Pages, an anonymous user is assigned an Anonymous role. This Anonymous role has certain default rights, which can potentially be exploited to access data that the user would not otherwise be able to see. Taking this a step further, many Anonymous users can self-register and, through misconfigurations in access controls for tables and their columns, expand the amount of data they are able to access.

The author, Aaron Costello, notes the impact of this particular misconfiguration issue:

“These exposures are significant – Microsoft Power Pages is used by over 250 million users every month, as well as industry-leading organizations and government entities, spanning financial services, healthcare, automotive and more. AppOmni’s discovery highlights the significant risks posed by misconfigured access controls in SaaS applications: Sensitive information, including personal details, has been exposed here. It’s clear that organizations need to prioritize security when managing external-facing websites, and balance ease of use with security in SaaS platforms – these are the applications holding the bulk of confidential corporate data today, and attackers are targeting them as a way into enterprise networks.”

How it Works

This particular misconfiguration issue arises due to some configuration quirks in Power Pages. Power Pages has three “out-of-the-box” roles that it buckets all users into, with two in particular, Anonymous and Authenticated, being at the core of this problem.

In addition to these two role controls, there are also access levels that restrict data access:

• Record level: The rows of data a user can see
• Column level: The columns of data a user can see
• Table level: The tables of data a user can see
• Site level: The base site authentication settings and the accessibility of tables with the Web API

These access controls are layered. In essence, if a user passes controls at the record level, they then are put through controls at the column level, and so on. Where this issue comes into play is in the configuration of specific values for sensitive data compared to the controls for each user.

Walking Through the Vulnerability

Let’s start at the beginning. A developer has created a site and has made a table to store their data. This table is assigned an allow-list entry for all columns, which results in the columns becoming retrievable by default through the Web API. With the Web API serving the data (even if that data is not accessible via the web), any user who enters the API can see that data.

A user enters the site. While no login page is hosted on the site, the Web API is configured by default to allow for self-registration and login. The Anonymous user, who is already given global table read by default, can identify the data that they want to target. From here, they can register their account and convert themselves to an Authenticated user.

Because of the default configurations and potential misconfigurations at the column level, as well as the global access for read operations, the user would be able to find a table and read columns through the Web API regardless of the resource-level access control.

The report from AppOmni breaks down some specific causes and contributors. Firstly, it notes that the Web API itself exposes excessive columns. While this isn’t itself an issue, it becomes an issue with the open registration and external authentication within the default site deployment. In this combinatory reality, the columns are exposed so that the global access table provision for default external users is overly verbose, revealing much more information than might be obvious outside of the API.

Some additional issues add up to make this even more significant. Poor column security for sensitive column data, poor (or absent) masking, and other issues ultimately result in the API surfacing much more data than might otherwise be obvious through mechanisms that are meant to be protective.

Evidence in the Wild

This is not a theoretical vulnerability — it has observable real-world examples of data exposure. In testing, AppOmni discovered the vulnerability was commonplace, with many organizations having the same default configurations and issues with role-based access controls. The problem was so significant that the exposure records already in the wild numbered in the millions:

“In one case, a large shared business service provider for the NHS was leaking the information of over 1.1 million NHS employees, with large portions of the data including email addresses, telephone numbers, and even home addresses of the employees. This particular finding was responsibly disclosed and has since been resolved.”

Mitigating Misconfigurations

While this individual case study shows how widespread this problem is, solving API misconfigurations is luckily quite easy if you pay attention and adequately address fixing them.

First and foremost, you need to be highly attentive. Microsoft Power Pages give ample warnings for the Anonymous role and the viewable nature of default sites, but these systems are often deployed with their default configurations. Ignoring the warnings during development is anathema to a strong developer culture of security. So, half the solution comes down to educating your team and enforcing rigorous standards verification.

Another huge step is to routinely audit controls and rights. Default configurations are one thing, but when those configurations exist months or years after a site is deployed, this suggests a major fault in the validation process. Your roles and access controls at individual resource and record levels should be routinely audited, both using automated and manual testing methodologies. The only way to ensure your configuration is accurate is to check your configuration. This should be a core part of the development lifecycle.

Continual monitoring is also a major part of the solution. There are clear warning signs that these problems exist, such as seeing Anonymous users accessing global data stores. Those signs should be measured and monitored in your system so you can detect and mitigate these threats as they are leveraged. Without this, you only have your theoretical tracking and safety net to lean back on.

Finally, conducting regular design reviews must become a part of your process. When putting content live, you should know well before deployment that you have a stable system with proper rights and access control. If you cannot ensure the build is correct, you should not deploy it — full stop.

Conclusion

We hope that this has helped you build a more securely configured solution. APIs require a lot of attention, and it can be easy to forget basic things like proper configuration. While often easy to address, API configurations can nonetheless be incredibly damaging, leading to reputational, financial, and regulatory issues.