Information Disclosure in APIs

Information disclosure occurs when an API unintentionally reveals sensitive data to unauthorized users. This vulnerability happens when APIs return more information than necessary, expose internal system details, or leak data through error messages, response headers, or debug endpoints.

Unlike injection attacks that require malicious input, information disclosure often works with legitimate requests. An attacker simply observes what the API returns and extracts valuable intelligence—like database schemas, internal IP addresses, software versions, or user data—that should remain hidden.

Common information disclosure vectors include:

• Verbose error messages that reveal stack traces or database queries
• HTTP response headers exposing server versions or internal architecture
• Debug endpoints accidentally left enabled in production
• API responses containing more user data than the requester should see
• Directory listing or file path exposure
• API keys or credentials embedded in client-side code

Information disclosure might seem minor compared to injection or authentication bypasses, but it often serves as the critical first step in sophisticated attacks. Attackers use exposed information to:

• Map attack surfaces: Internal IP addresses, server versions, and technology stacks help attackers identify vulnerable systems
• Craft targeted exploits: Knowing specific software versions allows attackers to use precise exploits from vulnerability databases
• Perform social engineering: Employee names, internal processes, and organizational structure aid phishing campaigns
• Access unauthorized data: APIs might return full user profiles when only basic information is needed
• Identify API endpoints: Exposed documentation or debug routes reveal undocumented endpoints

A real-world example: In 2021, a major cloud provider's API returned detailed error messages including database query structures and internal service names. Attackers used this information to identify SQL injection opportunities and map internal network architecture, leading to a significant data breach.

Detecting information disclosure requires systematic testing of API responses. Here's what to examine:

• HTTP response headers: Look for Server, X-Powered-By, X-AspNet-Version, and similar headers that reveal technology stacks
• Error messages: Test with invalid inputs and observe if stack traces, database errors, or internal paths are exposed
• Response payloads: Verify that responses contain only the data the requester should access
• Debug endpoints: Check for /debug, /status, or similar endpoints that might expose internal state
• Version information: APIs should never reveal specific software versions in production

How middleBrick detects information disclosure: middleBrick's black-box scanning automatically tests for information disclosure by examining HTTP response headers, analyzing error message content, and validating that API responses contain only authorized data. The scanner checks for common disclosure patterns like stack traces, internal IP addresses, and verbose error messages. When information disclosure is detected, middleBrick provides specific findings with the exact data exposed and severity levels based on the sensitivity of the disclosed information.

Preventing information disclosure requires a defense-in-depth approach. Here are concrete fixes:

1. Configure Proper Error Handling

// BAD: Exposes internal details
app.get('/api/users/:id', async (req, res) => {
  try {
    const user = await db.query('SELECT * FROM users WHERE id = ?', [req.params.id]);
    res.json(user);
  } catch (err) {
    res.status(500).json({ error: err.message }); // Exposes error details
  }
});

// GOOD: Generic error messages
app.get('/api/users/:id', async (req, res) => {
  try {
    const user = await db.query('SELECT * FROM users WHERE id = ?', [req.params.id]);
    res.json(user);
  } catch (err) {
    console.error('Database error:', err); // Log details internally
    res.status(500).json({ error: 'An internal error occurred' }); // Generic message
  }
});

2. Remove Sensitive Headers

// Remove version headers
app.use((req, res, next) => {
  res.removeHeader('X-Powered-By');
  res.removeHeader('Server');
  next();
});

// Set generic server header
app.use((req, res, next) => {
  res.set('Server', 'middleBrick-Protected');
  next();
});

3. Validate Response Data

// BAD: Returns full user object
async function getUserProfile(userId, requesterId) {
  const user = await User.findById(userId);
  return user; // Exposes all user data
}

// GOOD: Returns only authorized data
async function getUserProfile(userId, requesterId) {
  const user = await User.findById(userId);
  
  // Check if requester has permission
  if (!canViewFullProfile(requesterId, userId)) {
    return {
      id: user.id,
      name: user.name,
      email: user.email // Only public fields
    };
  }
  
  return user; // Full data for authorized users
}

4. Disable Debug Endpoints in Production

const isProduction = process.env.NODE_ENV === 'production';

// Only enable debug endpoints in non-production
if (!isProduction) {
  app.get('/debug/status', (req, res) => {
    res.json({
      uptime: process.uptime(),
      memory: process.memoryUsage(),
      env: process.env.NODE_ENV
    });
  });
}

Information disclosure vulnerabilities have caused significant real-world damage. In 2020, a popular e-commerce platform exposed detailed error messages that revealed database table structures and column names. Attackers used this information to craft precise SQL injection attacks, resulting in the theft of over 100,000 customer records.

Another notable case involved a financial services API that returned verbose error messages containing internal service URLs and database connection strings. This information enabled attackers to identify and target specific backend services, leading to a multi-stage attack that compromised customer financial data.

Even seemingly minor disclosures can have major consequences. A social media platform once exposed user ID sequences in API responses, allowing attackers to enumerate user accounts and build extensive user databases through automated scraping. The platform had to implement rate limiting and request authentication to mitigate the issue.

The OWASP API Security Top 10 lists "Broken Object Level Authorization" (API1:2023) and "Unrestricted Resource Consumption" (API4:2023) as critical risks, both of which often involve information disclosure as a precursor attack. Attackers frequently use exposed information to identify which resources they can access and how to manipulate API behavior.