Information Disclosure Pentest
Your API Just Told Me Everything I Needed to Know

// What your API returns when someone probes for data:

// BAD: Information disclosure vulnerability in action
{
  "error": true,
  "message": "Access denied: User john.doe@company.com cannot 
              view credit_card records for account #45821",
  "debug": {
    "query": "SELECT * FROM payments WHERE user_id = 45821",
    "table": "payments",
    "columns": ["id", "user_id", "credit_card_number", "cvv", "expiry"],
    "server": "db-prod-east-2.internal.company.com"
  }
}

// What an attacker learns:
// 1. The email format your company uses
// 2. Account numbers are sequential integers (enumerable)
// 3. Your database schema including sensitive column names
// 4. You store CVV codes (PCI compliance violation)
// 5. Your internal server naming convention

// GOOD: Secure error response
{
  "error": true,
  "message": "Access denied",
  "requestId": "req_x7k9m2p4"  // For internal debugging only
}

// The API endpoint: GET /api/users/profile

// What the frontend displays:
// Name: John Smith
// Email: john@example.com

// What the API actually returns (check Network tab):
{
  "id": 45821,
  "name": "John Smith",
  "email": "john@example.com",
  "phone": "+1-555-0123",
  "ssn": "123-45-6789",          // Credit card information leak!
  "payment_methods": [
    {
      "type": "credit_card",
      "number": "4532015112830366",  // Full card number exposed
      "cvv": "847",                   // CVV should NEVER be stored
      "expiry": "03/2027",
      "billing_address": "123 Main St, New York, NY 10001"
    }
  ],
  "internal_notes": "VIP customer - approved for $50k credit line",
  "created_at": "2019-03-15T08:22:14Z"
}

// The frontend only uses name and email
// But the ENTIRE response goes to the browser
// Attackers just open DevTools to see everything

// The fix: Only return what is needed
{
  "name": "John Smith",
  "email": "john@example.com"
}

// Probing for valid usernames:

// Request 1: Non-existent user
POST /api/login
{"email": "definitely.fake@random.com", "password": "test"}

Response: {
  "error": "No account found with that email"  // User does NOT exist
}

// Request 2: Valid user (wrong password)  
POST /api/login
{"email": "real.employee@company.com", "password": "test"}

Response: {
  "error": "Invalid password"  // User EXISTS!
}

// Even worse - timing-based disclosure:
// Invalid user: 50ms response (immediate rejection)
// Valid user: 250ms response (password hash comparison)

// Attackers can now:
// 1. Build a list of valid email addresses
// 2. Target those accounts for password spraying
// 3. Use the emails for phishing campaigns
// 4. Sell the validated email list

// SECURE: Consistent response for both cases
Response: {
  "error": "Invalid email or password"
}
// AND ensure consistent response timing

// Common debug endpoints found in production:

/debug               - Application debugging console
/phpinfo.php         - Complete PHP configuration exposure
/server-status       - Apache server metrics and connections
/actuator/env        - Spring Boot environment variables
/graphql/playground  - Interactive GraphQL interface
/.git/config         - Git repository configuration
/api/swagger.json    - Complete API documentation
/elmah.axd           - .NET error logs with stack traces
/__debug__/          - Framework debug toolbars

// What attackers find in exposed debug endpoints:

{
  "environment": "production",  // Oops
  "database": {
    "host": "db.internal.company.com",
    "user": "app_production",
    "password": "Pr0d_DB_2024!",  // Credentials in debug output
    "database": "customers_prod"
  },
  "stripe_api_key": "sk_live_51ABC...",  // Payment API keys
  "jwt_secret": "super-secret-key-123",  // Token signing key
  "aws_access_key": "AKIA...",           // Cloud credentials
  "internal_api_tokens": {
    "payment_gateway": "tok_prod_xyz",
    "email_service": "key_123abc"
  }
}

// One debug endpoint exposure = complete system compromise

// Attack chain starting from information disclosure:

// Step 1: Find verbose error message
GET /api/users/99999999
Response: "User not found in table 'users' (MySQL 8.0.28)"
// Learned: MySQL database, table name, potential injection point

// Step 2: Enumerate valid users through response differences  
GET /api/users/1 -> 403 Forbidden (user exists!)
GET /api/users/2 -> 403 Forbidden (user exists!)
GET /api/users/3 -> 404 Not Found (does not exist)
// Learned: Valid user IDs are 1 and 2

// Step 3: Find exposed API documentation
GET /swagger.json
// Learned: All API endpoints including admin functions

// Step 4: Discover debug endpoint
GET /actuator/env
// Learned: Database credentials, API keys, JWT secret

// Step 5: Access admin endpoint with JWT forgery
// Using the leaked jwt_secret to create admin token

// Step 6: Full database access
// Download complete customer table including credit cards

// Total time from first request to breach: 47 minutes
// Root cause: Information disclosure at every step