enterprise security

SecurityTrails Blog · Jun 14 · by Esteban Borges

How to detect developer mistakes before the bad guys do

Reading time: 7 minutes
Listen to this article

Web development is one of the largest, if not the largest, sectors in the current tech space. Everything you see on the internet falls more or less into the web development category, which ranges from basic website UI and UX development to complete application frontends and backends. And the surface area of web development is probably the largest it’s ever been.

With a steep increase in the automation of various tasks from running code tests to deployments, the rate of development seen in the web development market has increased to a level never seen before, with free-to-use and popular collaboration and code development platforms like GitHub and GitLab now offering various tools like Actions and CI/CD, allowing for completely automated testing and deployment of code pushed via every single commit made into your repository.

With each of these automated actions requiring staging or production host information (hostnames, IP addresses), various 3rd party API tokens, and SSH keys to log into production or staging environments, misconfigurations of these automated tasks (such as not sanitizing these config files before deploying, or not configuring repository access correctly) can lead to API keys, SSH keys, production host and other confidential information leaking out from your organization.

While educating dev teams is an essential part of any cybersecurity training, you must also rely on attack surface management platforms to keep an eye on all of your existing assets, and the misconfigurations and vulnerabilities present on each.

Dev mistakes and how Attack Surface Intelligence helps to detect them

The most popular development mistakes arise from the lack of code sanitization and associated configuration files being pushed into production. Luckily there are ways to detect such mistakes with the help of Attack Surface Intelligence.

.env files

Modern web development frameworks often use global configuration files like .env, and other developments and testing configurations are found within Git repositories, which are needed to automate various tasks such as testing and deployment.

These configuration files, such as the popular .env file, often contain API keys, sensitive production server hostnames, and other critical credentials such as database access credentials as well. In recent years, more than 100,000 GitHub repositories have had leaked API keys and various other sensitive credentials.

Configuration files - .env files

Popular web frameworks such as Laravel have had CVEs published in the past about this very issue since the .env file more or less contains the “keys” to your entire web application. From database credentials to 3rd party API keys to mail-server credentials, the .env file contains it all.

Luckily, ASI comes up with predefined rules to catch these misconfigurations on any host of your infrastructure, and in the blink of an eye:

ASI - catch misconfigurations

phpinfo Files

As the name suggests, phpinfo files are used to display detailed configurational information of the popular web development language PHP. Information about the various enabled modules and other configuration settings such as memory limits, paths, file size limits, and more can be viewed via this script.

phpinfo Files

phpinfo files also display the most basic yet critical information, which is the PHP version running on the server. If a version of PHP is vulnerable and/or has a CVE listing for it, it can lead to attackers easily compromising a server.

phpinfo scripts should be checked for and always made inaccessible, or simply removed when pushing code or servers into production. But if any of your devs forget that essential rule, ASI can detect any such phpinfo files in the wild easily, as you can see in the following screenshot:

phpinfo Files detection

Developer/debug mode

Similar to the phpinfo Files, debug or developer mode settings are often used to easily debug web applications during the development stage. By default, errors are written out to log files that are accessible via the CLI, which can be a time-consuming process to check every time.

To speed up the development process, the developer/debug modes are enabled, which then print errors right onto the web page being developed/viewed. While this is ideal during the development stage, displaying detailed errors (which can include full file paths, users executing the file, and other critical error information such as SQL queries that may have errored) can be dangerous and can also lead to attackers easily compromising your application.

Developer/debug mode

For example, in the recent past, Laravel had a security vulnerability in the ignition package that it uses, leading to users being compromised and cryptocurrency miners being installed onto systems that had developer mode enabled within Laravel at the time. This is a pretty common mistake that affects almost all platforms—here’s another example with Django:

In other cases, such as the Springboot Env Actuator, developers often leave environment variables exposed to the public, as shown in the following screenshot:

Environment variables exposed

Disabling developer/debug mode before pushing code into production should be a critical step in any web development process.

Publicly accessible SQL files

Developers and DevOps teams frequently need to generate dumps of SQL data in order to migrate data from one cloud instance to another; at other times, they simply need to generate a backup of the database quickly. The bad thing is that many times they just end up leaving the database SQL dump in a public place, where crawlers can read it, and furthermore, bad guys can take advantage of that to steal sensitive data from the clients or the company.

By using a simple Google Dork, we were able to find this exposed database belonging to a prestigious US university. However, multiple combinations of Google Dorks and other techniques are often needed to fully gain visibility over your exposed SQL databases, which makes the task time-consuming—especially if your organization has hundreds or thousands of digital assets.

Publicly accessible SQL files

For these cases, ASI becomes your best ally for finding exposed SQL dumps. Thanks to our exposure signatures, we’re able to find these typical SQL dumps really quickly across all of your hosts:

finding exposed SQL dumps

Using self-signed certificates

As previously covered in our Danger of Self-Signed SSL Certificates blog post, while the usage of self-signed certificates has diminished in recent times due to free-to-use projects like LetsEncrypt providing SSL certificates for free, using self-signed certificates remains commonplace in the majority of older projects which have not yet transitioned to using services like LetsEncrypt for their SSL requirements.

This leads to the age-old SSL issue that, if leaked, attackers can easily set up phishing pages that would appear normal and trusted, since these self-signed certificates would be pre-trusted and installed onto developer systems.

Using self-signed certificates

Other popular examples of exposed data by developers include but are not limited to PHP User.ini Disclosure and ColdFusion cfcache.map files, Common error log files, publicly accessible NPM log files, Laravel log files publicly accessible, Magento unprotected development files, and many others!

This is just a fraction of ASI’s real power when finding developer mistakes that may lead to data exposure on your infrastructure.


Automation in web development has come a long way. While initially seen only in the handling of basic tasks such as packaging releases and automating bug report filing, automation in web development today can cover all areas involved, from testing code to compiling code to even deploying code to production instances.

With all the advantages automation provides, there are certain risks with it as well, as the scripts running various automated tasks would need access to anything a human would require when running the same tasks manually. Such required access includes everything from API keys, mail server access, database access credentials, and SSH keys for logging in to servers.

Dev misconfigurations come in various forms, such as allowing public access to configurational files, accidentally leaving information disclosure files like phpinfo files, or leaving debug mode enabled for users to access. Each small misconfiguration can lead to a large amount of access to, and intel about your web applications platform.

All risks considered, discarding or reducing the use of automation within web development is simply no longer an option. The ideal balance of having all the advantages of automation while remaining safe begins with employing the use of effective attack surface management tools such as our own Attack Surface Intelligence platform, which can help identify these deployment or automation flaws within your organization.

Esteban Borges Blog Author

Esteban is a seasoned cybersecurity specialist, and marketing manager with nearly 20 years of experience. Since joining SecurityTrails in 2017 he’s been our go-to for technical server security and source intelligence info.