Mishandling of Exceptional Conditions

When something unexpected happens, the app leaks information, crashes, or fails open.

## 1 · why it happens

New in 2025. Developers write the happy path; attackers live in the error paths. An unexpected type, a missing field or a timeout can produce a stack trace, skip a security check, or leave a transaction half-done.

Errors are also one of the richest OSINT sources: a single stack trace can reveal the framework, its version, file paths, database type and internal hostnames.

# JavaScript

✗ vulnerable

async function canAccess(user, doc) {
  try {
    return await policyService.check(user, doc);
  } catch (e) {
    return true;   // fail open: policy service down = everyone allowed
  }
}

✓ fixed

async function canAccess(user, doc) {
  try {
    return await policyService.check(user, doc);
  } catch (e) {
    logger.error({ event: 'policy_check_failed', err: e.message });
    return false;  // fail closed
  }
}

# C#

✗ vulnerable

catch (Exception ex)
{
    return StatusCode(500, ex.ToString()); // stack trace, paths, SQL
}

✓ fixed

catch (Exception ex)
{
    _logger.LogError(ex, "Order failed {OrderId}", id);
    return Problem("Something went wrong.", statusCode: 500);
}

## 2 · how attackers find it from outside

public source	what it tells them
Search engines	Indexed error pages and stack traces from your site.
Wayback Machine	Old error pages captured before you fixed them - the versions may still be the same.
Your own app	Send a single quote, an array instead of a string, or an empty body - what comes back?

→ all OSINT sources · run them on yourself

## 3 · how it's abused

⚠ Recon your own assets, or targets you have written permission to test. Passive OSINT reads public data, but using it to target someone else's systems can still be illegal or against their terms. Examples on this site use example.com placeholders.

A single quote often triggers a database error that reveals the query and the database type.