Information Disclosure Issues and Attacks in Web Applications

Information disclosure is when an application fails to properly protect sensitive information from parties that are not supposed to have access to such information in normal circumstances. These type of issues are not exploitable in most cases, but are considered as web application security issues because they allows attackers to gather information which can be used later in the attack lifecycle, in order to achieve more than they could if they didn’t get access to such information.

Information disclosure issues can range in the criticality of the information leaked, from disclosing details about the server environment to the leakage of administrative accounts credentials or API secret keys, which may have devastating outcomes on the vulnerable web application.

Different Types of Information Disclosure Issues

The list below highlights a number of information disclosure issues in web applications. The list also includes examples about every information disclosure security issue and explains how each of them can be discovered.

Banner Grabbing/Active Reconnaissance:

Banner grabbing or active reconnaissance is a type of attack during which the attackers send requests to the system they are attempting to attack in order to gather more information about it. If the system is not well configured, it may leak information about itself, such as the server version, PHP/ASP.NET version, OpenSSH version, etc.

In most cases, banner grabbing does not involve the leakage of critical pieces of information, but rather information that may aid the attacker through the exploitation phase of the attack. For example, if target leaks the version of PHP it is running on the server, and it happens to be vulnerable to Remote Command/Code Execution (RCE) because it wasn’t updated, the attackers may exploit the known vulnerability and take full control of the web application.

Example of Banner Grabbing

Netsparker identifies an outdated installation of PHP on the target server

In the above example we can see that Netsparker identified an old version of PHP running on the target host. You can also use the HTTP Request / Response tab in Netsparker to see the HTTP response from the target service in raw format, in which the old version of PHP is highlighted as well.

View the HTTP response in Netsparker which highlights the outdated version of PHP

Source Code Disclosure

Source code disclosure issues occur when the code of the backend environment of a web application is exposed to the public. Source code disclosure enables attackers to understand how the application behaves by simply reading the code and checking for logical flaws, or hardcoded username/password pairs, or API secret keys. The severity here depends on how much of the code is exposed, and how critical the leaked lines of code are for the security of the web application. In short, source code disclosure turns a black box testing process into more of a white box testing approach since attackers get access to the code.

Source code disclosure issues can occur in numerous ways, below are some of them:

Unprotected Public Code Repositories

Many often host their source code in the cloud in order to improve collaborative development methods. Such repositories are sometimes not well protected and may allow attackers to access the hosted source code and information. Also, some companies which develop open source software use public repositories so that the public can contribute to the project. In this case the source code is already public, but it is not the first time the publicly available source code contained sensitive information.

Example of Unprotected Source Code Repository

Some source code repositories only allow users to see their content based on an authentication process. Such repositories are sometimes ill configured, leaving their content accessible to anyone that for example has a particular email address, failing to restrict access to certain accounts that should have such levels of access.

Netsparker detected a source code repository on the target website.

Netsparker scanner identified a SVN repository on the target wesite

Another example is when the public code has sensitive information hard coded in it, such as user credentials or API secret keys. Attackers can easily use such information to sabotage these services or cause accessibility issues for legitimate users. Another piece of information that is typically disclosed during information disclosure are internal IP addresses, allowing attackers to identify and learn about the internal network topology. Such information can then be used to pivot into the network and attack multiple systems via a Server Side Request Forgery (SSRF) attack for example.

Incorrect MIME Types

Web browsers know how to parse the information they receive from the Content-Type HTTP header, which is sent by the web server in the HTTP response. For example in the screenshot below we can see that the Content-Type header is set to text/html, so the browser parses the HTML and shows the output.

The MIME type in the HTTP header instructing the browser that the data it is receiving is HTML.

Though if the web server is misconfigured, and for example it sends the header Content-Type: text/plain instead of Content-Type:text/html when serving a HTML page, the code will be rendered as plain text in the browser, allowing the attacker to see the source code of the page.

Inappropriate Handling of Sensitive Data

Another common mistake is hardcoding important information such as username/password pairs, internal IP addresses in scripts and comments in code and web pages. In most cases such information is released on the production web application . The disclosure of such information may cause ravaging outcomes for the web application; all the attacker has to do is to look for such information in the source of those web pages (i.e by doing a right click on the page and then selecting “View Page Source”, do not confuse with “Source code”). Netsparker will alert you if it finds possible sensitive information in the comments of the web application.

File Name & File Path Disclosure

In some circumstances web applications can disclose file names or file paths, thus revealing information about the structure of the underlying system. This can happen due to incorrect handling of user input, exceptions at the backend, or inappropriate configuration of the web server. Sometimes such information can be found or identified in the responses of the web applications, error pages, debugging information etc.

Example of File Name & Path Disclosure

A simple test an attacker can do to check if the web application discloses any file names or paths is to send a number of different requests that he thinks the target might handle differently. For example when sending the below request the web application returns a 403 (Forbidden) response:

But when the attacker sends the following sequence, he gets a 404 (Not found) response:

Since for the first request the attacker got a 403 Forbidden error and for the second one he got a 404 Not Found, he knows that in the first case the file in question exists. Therefore the attacker can use the web application’s behaviour to his advantage, as an exploit to understand how the server is structured and to verify whether a certain folder or file exists on the system.

Directory Listing

Related to filename and path disclosure is directory listing in web servers. This functionality is provided by default on web servers. When there is no default web page to show the web server shows the user a list of files and directories present on the website.

Therefore if the default filename on an Apache web server is index.php, and you have not uploaded a file called index.php in the root directory of your website, the server will show a directory listing of the root directory instead of parsing the php file, as shown in the below screenshot.

Apache showing the directory listing of a website rather than the website itself.

Leaving such functionality enabled in production environments is a bad practice and can lead to bigger security issues.

Example of How Directory Listing Can Be Used To Attack a Target

Nowadays many are aware that such functionality should be disabled, so it is not common to see it. Though let’s assume that after scanning the ports of a web server, the attacker found a default installation of the web server running on the port 8081.

Such “defaults” are typically overlooked by web server administrators, which also means they are much less secure. The installation may also have directory listing enabled, allowing the attacker to navigate through the directories and access source code, backup and possible database files of the web application.

Mitigation Against Information Disclosure

Information disclosure security issues might seem like trivial issues, but they are not. They allow the attackers to gain insightful information about the target they are willing to attack, just by performing basic testing, and sometimes just by looking for information in public pages. In fact Netsparker reports information disclosure issues, and in the Knowledge Base node it also reports any possible sensitive comments found in the code of the target website.

Therefore you should always address these issues, especially when you consider that they are really easy to mitigate against. The following are some guidelines to follow so you can make sure that your web applications are well protected against the most obvious information disclosure issues:

  • Make sure that your web server does not send out response headers that reveal information about the backend technology type or version.
  • Make sure that all the services running on the server’s open ports do not reveal information about their builds and versions.
  • Always make sure that proper access controls and authorizations are in place in order to disallow access for attackers on all web servers, services and web applications.
  • Do not hard code credentials, API keys, IP addresses, or any other sensitive information in the code, not even in the form of comments.
  • Configure the correct MIME types on your web server for all the different files being used in your web applications.
  • Sensitive data or files that do not need to be on the web servers should never be uploaded on the web server.
  • Always check whether each of the requests to create/edit/view/delete resources has proper access controls, preventing privilege escalation issues and making sure that all the confidential information remains confidential.
  • Make sure that your web application processes user input correctly, and that a generic response is always returned for all the resources that don’t exist/are disallowed in order to confuse attackers.
  • Enough validations should be employed by the backend code in order to catch all the exceptions and prevent the leakage of valuable information.
  • Configure the web server to suppress any exceptions that may arise and return a generic error page.
  • Configure the web server to disallow directory listing and make sure that the web application always shows a default web page.


Dead accurate, fast & easy-to-use Web Application Security Scanner