Back to Vulnerability Database

Exposure of Sensitive Information Due to Incompatible Policies

Description

Exposure of Sensitive Information Due to Incompatible Policies is a vulnerability that occurs when a product's intended functionality exposes information according to the developer's security policy, but this information is considered sensitive according to the security policies of other stakeholders. The fundamental issue arises from a mismatch between what developers consider acceptable to expose and what users, administrators, or regulatory frameworks consider sensitive. This disconnect often manifests when applications display personal data like social security numbers, expose system configuration through debugging functions, or reveal internal identifiers that different stakeholders have varying expectations about protecting. The weakness highlights the importance of considering multiple perspectives when determining what constitutes sensitive information.

Risk

Incompatible security policies create significant risks because sensitive information may be exposed even when developers believe they are following proper security practices. Personal data exposure can lead to identity theft, privacy violations, and regulatory non-compliance with laws like GDPR, HIPAA, or CCPA. Technical information exposure through functions like phpinfo() can reveal software versions, configuration settings, and server paths that aid attackers in planning targeted attacks. Business-sensitive information such as internal user identifiers, pricing algorithms, or customer data may be inadvertently shared with users who then expose it further. The risk is amplified because the exposure is by design rather than by accident, making it systematic and potentially affecting all users of the system.

Solution

Establish a comprehensive data classification framework that considers all stakeholder perspectives including users, administrators, regulators, and business partners. Conduct privacy impact assessments to identify information that any stakeholder might consider sensitive. Implement the principle of minimal disclosure - only expose information that is strictly necessary for functionality. Create configuration options allowing administrators to control what information is displayed based on their organization's policies. Remove or disable development features like phpinfo() and debug endpoints in production environments. Regularly review application outputs with representatives from different stakeholder groups. Implement data masking for sensitive fields and provide audit trails when sensitive information is accessed.

Common Consequences

ImpactDetails
ConfidentialityScope: Confidentiality

Sensitive information is read by unauthorized parties who should not have access according to their security policies. This may include personal data, system configuration, or business-sensitive information that different stakeholders expect to remain protected.

Example Code

Vulnerable Code (Java/JSP)

The following code demonstrates exposure of information that users would consider sensitive even though developers might not:

// Vulnerable JSP page - exposes sensitive user data without considering user expectations
<%@ page import="com.example.UserService" %>
<%
    UserService userService = new UserService();
    User user = userService.getCurrentUser();
%>

<!-- Vulnerable: Developer thinks this is "user profile" but exposes sensitive data -->
<html>
<head><title>User Profile</title></head>
<body>
    <h1>Welcome, <%= user.getFullName() %></h1>

    <!-- Users expect these to be private -->
    <div class="profile-details">
        <p>SSN: <%= user.getSocialSecurityNumber() %></p>
        <p>Date of Birth: <%= user.getDateOfBirth() %></p>
        <p>Home Address: <%= user.getHomeAddress() %></p>
        <p>Phone: <%= user.getPhoneNumber() %></p>
    </div>

    <!-- Credit card shown to "help users remember" -->
    <div class="payment-info">
        <p>Card Number: <%= user.getCreditCardNumber() %></p>
        <p>Expiry: <%= user.getCardExpiry() %></p>
    </div>

    <!-- Developer debug info left in production -->
    <div class="debug" style="display:none">
        <!-- Users and admins wouldn't expect this exposed -->
        <p>User ID: <%= user.getInternalId() %></p>
        <p>Account Type: <%= user.getAccountType() %></p>
        <p>Credit Score: <%= user.getCreditScore() %></p>
    </div>
</body>
</html>

// Vulnerable: phpinfo() equivalent in Java servlet
@WebServlet("/status")
public class StatusServlet extends HttpServlet {

    // Developer considers this "helpful" for support
    // But exposes sensitive system configuration
    protected void doGet(HttpServletRequest request, HttpServletResponse response) {
        PrintWriter out = response.getWriter();
        out.println("<h1>System Status</h1>");

        // Exposes all system properties - sensitive to admins
        out.println("<h2>System Properties</h2>");
        for (Object key : System.getProperties().keySet()) {
            out.println(key + "=" + System.getProperty((String)key) + "<br>");
        }

        // Exposes environment variables including secrets
        out.println("<h2>Environment Variables</h2>");
        for (Map.Entry<String, String> entry : System.getenv().entrySet()) {
            out.println(entry.getKey() + "=" + entry.getValue() + "<br>");
        }
    }
}

Fixed Code (Java/JSP)

// Fixed JSP page - respects user privacy expectations
<%@ page import="com.example.UserService" %>
<%@ page import="com.example.PrivacySettings" %>
<%
    UserService userService = new UserService();
    User user = userService.getCurrentUser();
    PrivacySettings privacy = user.getPrivacySettings();
%>

<html>
<head><title>User Profile</title></head>
<body>
    <h1>Welcome, <%= user.getDisplayName() %></h1>

    <div class="profile-details">
        <!-- Fixed: Only show masked versions, with user control -->
        <% if (privacy.showSsnLastFour()) { %>
            <p>SSN: XXX-XX-<%= user.getSsnLastFour() %></p>
        <% } else { %>
            <p>SSN: [Hidden - click to reveal]</p>
        <% } %>

        <!-- Fixed: Show only what user has explicitly allowed -->
        <% if (privacy.showDateOfBirth()) { %>
            <p>Date of Birth: <%= user.getFormattedDob() %></p>
        <% } %>

        <!-- Fixed: Never show full credit card -->
        <p>Card: **** **** **** <%= user.getCardLastFour() %></p>
    </div>

    <!-- Fixed: No debug info in production -->
</body>
</html>

// Fixed: Restricted status endpoint with proper access control
@WebServlet("/admin/status")
public class SecureStatusServlet extends HttpServlet {

    private static final Set<String> SAFE_PROPERTIES = Set.of(
        "java.version", "java.vendor", "os.name", "os.arch"
    );

    protected void doGet(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {

        // Fixed: Require admin authentication
        if (!isAdmin(request)) {
            response.sendError(HttpServletResponse.SC_FORBIDDEN);
            return;
        }

        PrintWriter out = response.getWriter();
        out.println("<h1>System Status</h1>");

        // Fixed: Only expose safe, non-sensitive properties
        out.println("<h2>System Information</h2>");
        for (String key : SAFE_PROPERTIES) {
            out.println(key + "=" + System.getProperty(key) + "<br>");
        }

        // Fixed: Never expose environment variables
        out.println("<p>Application version: " + getAppVersion() + "</p>");
        out.println("<p>Status: Healthy</p>");

        // Log the access for audit
        auditLogger.log("Status page accessed by: " + getAdminUsername(request));
    }

    private boolean isAdmin(HttpServletRequest request) {
        // Verify admin authentication and authorization
        return request.isUserInRole("ADMIN");
    }
}

The fix respects user privacy expectations by masking sensitive data, providing user control over visibility, removing debug information, and restricting system information endpoints to authorized administrators.

Exploited in the Wild

phpinfo() Exposure Incidents (Multiple Organizations, Ongoing)

The phpinfo() function has been a persistent source of information exposure in PHP applications. Security researchers regularly discover publicly accessible phpinfo pages that reveal database credentials in environment variables, internal network topology, file system paths, and installed module versions. Attackers use this information for targeted exploitation. Major vulnerability databases contain hundreds of CVEs related to phpinfo() exposure.

Social Security Number Exposure in Public Records (Various Government Sites, 2000s-2010s)

Multiple government websites exposed citizens' social security numbers through public records searches, voter registration databases, and court document systems. While developers considered this acceptable under their interpretation of public records laws, citizens and privacy advocates viewed SSNs as sensitive. These incidents led to legislative changes and stricter data protection requirements.

Telnet Environment Variable Leakage (Multiple Vendors, 2005)

CVE-2005-1205 and CVE-2005-0488 documented vulnerabilities where telnet clients would send sensitive environment variables (USER, HOME, PWD) to malicious telnet servers. While developers considered environment variables acceptable to share, users expected this information to remain local. The vulnerability was exploited to gather reconnaissance about connecting users.

Tools to Test/Exploit

  • Burp Suite — Web security testing platform for identifying exposed sensitive information in application responses.

  • Nuclei — Vulnerability scanner with templates for detecting phpinfo() and other information disclosure endpoints.

  • Google Dorks — Search techniques for finding exposed phpinfo pages and sensitive data on public websites.

CVE Examples

  • CVE-2002-1725 — Script calling phpinfo() exposed system configuration details to unauthorized users.

  • CVE-2005-1205 — Telnet client allowed servers to obtain sensitive environment variables from clients.

  • CVE-2003-1038 — Product listed DLLs and complete file pathnames, exposing system structure.

References

  1. MITRE Corporation. "CWE-213: Exposure of Sensitive Information Due to Incompatible Policies." Common Weakness Enumeration. https://cwe.mitre.org/data/definitions/213.html

  2. OWASP Foundation. "Information Exposure." OWASP. https://owasp.org/www-community/vulnerabilities/Information_exposure

  3. NIST. "Guide to Protecting the Confidentiality of Personally Identifiable Information (PII)." Special Publication 800-122. https://csrc.nist.gov/publications/detail/sp/800-122/final