Vulnerability Discussion

Any application providing too much information in error messages risks compromising the data and security of the application and system. The structure and content of error messages must be carefully considered by the organization and development team.

The extent to which information systems are able to identify and handle error conditions is guided by organizational policy and operational requirements. Information that could be exploited by adversaries includes, for example, erroneous logon attempts with passwords entered by mistake as the username, mission/business information that can be derived from (if not stated explicitly by) information recorded, and personal information, such as account numbers, social security numbers, and credit card numbers.

Mask or redact sensitive data in API responses.

Check

Review the API documentation and interview the API administrator for details regarding how the API displays error messages.

Utilize the API as a nonprivileged user and attempt to execute functionality that will generate error messages.

Review the error messages displayed to ensure no sensitive information is provided to end users.

If error messages are designed to provide users with just enough detail to pass along to support staff to aid in troubleshooting date, time, or other generic information, this is not a finding.

If variable names, SQL strings, system path information, or source or program code are displayed in error messages sent to nonprivileged users, this is a finding.

Fix

Build or configure the API to not send error messages containing system information or sensitive data to users.

Use generic error messages.