CWE Glossary

CWE is a trademark of the MITRE Corporation.

Stay in touch

Get our research, blog and event invitations before everybody else!

Your data will stay confidential Private and Confidential

Information Exposure [CWE-200]

This weakness describes intentional or unintentional disclosure of information that is considered sensitive.

Created: September 11, 2012
Latest Update: May 18, 2017

Table of Content

  1. Description
  2. Potential impact
  3. Attack patterns
  4. Affected software
  5. Exploitation Examples
  6. Severity and CVSS Scoring
  7. Mitigations
  8. References
  9. Latest Related Security Advisories

1. Description

This weakness could be result of numerous types of problems that involve exposure of sensitive information. The information is considered sensitive when:

  • It is sensitive within the product functionality (e.g. information with restricted access, private messages, etc.)
  • It contains data about the product itself, its environment or the related system that is not intended be disclosed by the application.

CWE-200 is a parent for the following weaknesses:

  • CWE-201: Information Exposure Through Sent Data
  • CWE-202: Exposure of Sensitive Data Through Data Queries
  • CWE-203: Information Exposure Through Discrepancy
  • CWE-209: Information Exposure Through an Error Message
  • CWE-211: Information Exposure Through Externally-Generated Error Message
  • CWE-212: Improper Cross-boundary Removal of Sensitive Data
  • CWE-213: Intentional Information Exposure
  • CWE-214: Information Exposure Through Process Environment
  • CWE-215: Information Exposure Through Debug Information
  • CWE-226: Sensitive Information Uncleared Before Release
  • CWE-497: Exposure of System Data to an Unauthorized Control Sphere
  • CWE-524: Information Exposure Through Caching
  • CWE-526: Information Exposure Through Environmental Variables
  • CWE-538: File and Directory Information Exposure
  • CWE-598: Information Exposure Through Query Strings in GET Request
  • CWE-612: Information Exposure Through Indexing of Private Data

2. Potential impact

Potential impact can vary depending on application, environment and other circumstances. There are many different problems that involve information leaks and their severity can be widely ranged based on information that is disclosed.

3. Attack patterns

The following CAPEC vectors are related to information disclosure weakness:

In WASC Threat Classification this weakness is described as an attack and weakness under WASC-45 (Fingerprinting) and WASC-13 (Information Leakage) respectively.

4. Affected software

Basically all types of software can be vulnerable to this issue.

5. Exploitation Examples

Let's have a look at the HTB23123 security advisory (CVE-2012-5696). The vulnerability allows a malicious user to access configuration file via HTTP request by accessing the file directly. We will use the following URL to access the configuration file:

The output is shown on the image below:

HTB23123 advisory (CVE-2012-5696) CWE-200 PoC exploitation example

As we can see, it is possible to view contents of the file that contains credentials for accessing the database along with other configuration options.

6. Severity and CVSS Scoring

When scoring information disclosure weaknesses security specialists must consider the maximum possible impact. If an attacker can gain access to certain parts of information or he does not have control over what is obtained the weakness should be scored as C:P. If an attacker is able to read all system data (e.g. files, memory) it should be scored as C:C. Usually, when information exposure is the only weakness presented in application it is scored as C:P.

For a web application disclosure of certain files should be scored as:
5 (AV:N/AC:L/Au:N/C:P/I:N/A:N) – Medium severity.

Vulnerabilities described in HTB22945 security advisory (Installation path disclosure weakness in ZENphoto) can be used as an example of this score.

However disclosure of application and system files should be scored as:
7.8 (AV:N/AC:L/Au:N/C:C/I:N/A:N) - High severity.

We use CVSSv2 scoring system in our HTB Security Advisories to calculate the risk of the discovered vulnerabilities. Not all of the vulnerabilities are scored in strict accordance to FIRST recommendations. Our CVSSv2 scores are based on our long internal experience in software auditing and penetration testing, taking into consideration a lot of practical nuances and details. Therefore, sometimes they may differ from those ones that are recommended by FIRST.

7. Mitigations

For CWE-211 [Information Exposure Through Externally-Generated Error Message] mitigation techniques please refer to this article.

The main approach in defending sensitive data is to use safe mechanisms to store and access information. But first, information assets should be identified in order to determine what exactly should be protected and how. There are certain certifications, standards and compliance requirements when dealing with classified information, which are far beyond the scope of this article. Here, however, we will try to provide basic understanding of information types and give general advices to developers. We suggest dividing information into two categories:

System information

It should be obvious from the category name that here we are talking about system related data, such as file system structure, system users, installed software, system log files, etc. This is basically any information that reveals environment of the application or asset. To prevent system information exposure follow these recommendations:

  1. General recommendations
    • Never run applications in debug mode on production servers,
    • Use least privilege approach and proper file system permissions,
    • Run remotely accessible applications in chroot/sandbox environments,
    • Never store log files with world-readable permissions;

  2. Web site environment
    • Disable directory listing to prevent exposure of web site structure and potentially sensitive files,
    • Use custom error pages that prevent from displaying excessive system information,
    • Disable error reporting output into the client’s browser,
    • Use IP-based approach to access sensitive directories or restrict access to directories otherwise.

You can use the following Cheat Sheet when configuring your webserver:

Action neededExamples
Disable debugging output
Change the value for “display_errors” to “off” in PHP configuration file php.ini: display_errors=0
Disable debugging output
Edit the Web.config file file and set “debug” attribute to “false”: <compilation
Disable debugging output
Use the cfsetting tag showDebugOutput attribute to turn off debugging output for a specific page: <cfsetting showDebugOutput="No">
Custom error pages
To add custom error pages follow instructions below:
To add a custom error, use the following syntax: appcmd set config /section:httpErrors /+"[statusCode=' int ',subStatusCode=' int ', prefixLanguageFilePath=' string ',path=' string ', responseMode = 'File|ExecuteURL|Redirect']" For more information on custom error pages refer to TechNet web site:
Custom error pages in
To change the default error pages use the “ErrorDocument” directive in your webserver configuration. These pages can be changed globally for every web site hosted by Apache HTTP server using httpd.conf file or for each site via .htaccess files. For example: ErrorDocument 500 "Sorry, our script crashed. Oh dear" For more information on custom error pages refer to official documentation:
Custom error pages
Use the following configuration to change the default error page: error_page {ErrNo} / {ErrNo}.html;
location /{ErrNo}.html {
where ErrNo is number of HTTP Error. For example: error_page 403 /403.html;
  location = /403.html {
    root html;
    allow all;
For more information refer to official documentation:
Restrict access
You can restrict access to sensitive script “/admin.php” using the following configuration: location = /admin.php {
  deny all;
Restrict access
You can restrict access to sensitive script “admin.aspx” using the following configuration: <location path="admin.aspx">
        <remove users="*" roles="" verbs="" />
        <add accessType="Allow" roles="Administrators" />
Restrict access
You can restrict access to sensitive script “admin.php” using the following configuration: <Files "admin.php">
  Order allow,deny
  Deny from all

Sensitive information

This category contains the actual information we want to protect, such as passwords, valuable data etc. Developers should always pay attention to privileges within the application and information that can be accessed by application itself. All sensitive data should be encrypted and stored in safe places. This particularly applies to:

  • Passwords,
  • Backup copies,
  • Any other information that might have a value for potential intruder (e.g. sensitive documents, sensitive configuration data, etc.).

When deploying the application, pay attention to files that may contain sensitive data as well as access control lists applied to these files. When dealing with web applications, place all sensitive content outside the webroot directory or make sure that access to these files is restricted to application itself (e.g. the file cannot be directly accessed using a web browser). Never output debug information to user’s browser, use log files outside the webroot directory instead.

8. References

  1. CWE-200: Information Exposure []
  2. Information Leakage []

9. Latest HTB Security Advisories with CWE-200

Copyright Disclaimer: Any above-mentioned content can be copied and used for non-commercial purposes only if proper credit to High-Tech Bridge is given.

↑ Back to Top
High-Tech Bridge on Facebook High-Tech Bridge on Twitter High-Tech Bridge on LinkedIn High-Tech Bridge RSS Feeds Send by Email