While most of the vulnerabilities on this list are pretty specific to APIs, the disabled security features/debug features enabled/improper permissions problem is one that can strike anywhere. It's likely a little more prevalent in APIs, but attackers will often attempt to find unpatched flaws and unprotected files or directories anywhere in a network. Coming across an API that has debugging enabled or security features disabled just makes their nefarious work a little easier. Worse yet, automated tools are available to detect and exploit security misconfigurations, so if you have them in your environment, there is a good chance that they will be exploited, which is why this vulnerability made the OWASP list of dangerous API flaws.

Before we get into the fun, see if you can solve this debug challenge:

How does the disabled security features/debug features enabled/improper permissions flaw sneak into an API?

To see how this multidimensional API flaw gets added to networks, we must break it down into its component parts. Let's start with the enabled debug features problem. Debugging is a useful tool that helps developers figure out why applications aren't performing correctly or making errors. With debugging enabled, errors and exceptions generate detailed error pages so developers can see what went wrong and fix problems. It's perfectly fine to have this active while an application is still in development.

However, there is a reason why most frameworks come with warnings about running debug mode in a production environment, likely right in the code where debugging is activated. For example:

# SECURITY WARNING: dont run with debug turned on in production!
DEBUG = True

In this example, debugging has been activated. The Django application will generate detailed error pages when an exception is raised. If this is done in a production environment, an adversary would have access to these error pages, which includes metadata information about the environment. Although most frameworks have debugging turned off by default, it's easy to forget to switch it back off if activated during a long development process. Then when the application moves to a production environment, it provides attackers with a lot of information about how to compromise an application, or even an entire server or network.

While enabling debug mode is mostly a standalone problem, the improper permissions and disabled security features vulnerabilities often work together. For example, in a real scenario provided by OWASP, an attacker used a search engine to find a database that was accidentally connected to the internet. Because the popular database management system was using its default configuration, authentication was disabled. Thus, by combining the improper permissions and disabled security features vulnerabilities, the attacker gained access to millions of records with PII, personal preferences and authentication data.

Eliminating the disabled security features/debug features enabled/improper permissions vulnerabilities

You probably need to make a two-pronged approach in eliminating this vulnerability. To remove the enabled debug part of the problem, simply add a check to the development process to ensure that debugging is disabled before moving an API or application to the production environment. From our example, the proper command to do that would be as follows:

# SECURITY WARNING: dont run with debug turned on in production!
DEBUG = False

Now debug features in the Django application are disabled with the DEBUG flag configured to False. No error pages will be generated in response to errors. If an adversary still gains access to error pages, they won't contain any useful metadata, and won't pose a risk to the application.

Eliminating disabled security features and improper permissions vulnerabilities is a bit more difficult because they can encompass a wide range of specific vulnerabilities. The best way to stop them is to develop a standard and repeatable process to allow for the fast and easy deployment of locked down assets to the production environment.

Even then, you should create a process where orchestration files, API components, and cloud services like Amazon S3 bucket permissions are constantly reviewed and updated. This review should also rate the overall effectiveness of security settings across the entire environment over time to make sure the organization is always improving its API security.

Check out the Secure Code Warrior blog pages for more insight about this vulnerability and how to protect your organization and customers from the ravages of other security flaws. You can also try a demo of the Secure Code Warrior training platform to keep all your cybersecurity skills honed and up-to-date.