Improve error handling: Remove exception details from API responses

[Pritz395]

Summary

Multiple API endpoints are returning raw exception messages (str(e)) in JSON responses, which can leak internal system information. While not exposing credentials directly, this violates security best practices and can aid attackers in reconnaissance.

Problem

Exception messages in API responses can reveal:

• Internal service URLs (e.g., ORD_SERVER_URL endpoints in network errors)
• Library versions and dependencies (if present in error messages)
• System architecture hints (service names, internal paths)
• Implementation details (error handling patterns, validation logic)

Note: This does NOT expose API keys, passwords, or credentials directly. However, it's still an information disclosure issue that should be addressed as a defense-in-depth measure.

Affected Endpoints

website/views/repo.py (7 instances)

• Lines 257, 275: AI summary generation errors
• Line 297: Section refresh operation errors
• Line 445: GitHub API error handling
• Line 565: Repository add operation errors
• Lines 629, 647: Command execution errors (also exposes error_type field)

website/views/bitcoin.py (1 instance)

• Line 89: RequestException in pending transactions view (could expose ORD_SERVER_URL)

website/views/core.py (2 instances)

• Lines 1552, 1554: Roadmap PR submission errors

website/views/organization.py (2 instances)

• Lines 2881, 2884: Message creation stream errors

Example

Current behavior:
{
"status": "error",
"message": "Connection refused: http://internal-service:9001/send-bacon-tokens"
}What this reveals:

• Internal service endpoint URL
• Service port number
• Service name/functionality

Recommended behavior:
{
"status": "error",
"message": "An error occurred while processing your request. Please try again later."
}## Recommended Fix

1. Log full exception details server-side with logger.error(..., exc_info=True)
2. Return generic, user-friendly error messages to clients
3. Remove error_type field from error responses (lines 629, 647 in repo.py)

Impact

• Severity: Low-Medium (Information Disclosure)
• CVSS: ~3.1 (Low) - Information Exposure
• Priority: Best Practice / Defense-in-Depth
• Exploitability: Low (requires error conditions to trigger)

Additional Improvements Included

• Fix TransactionManagementError logging in blt/middleware/ip_restrict.py (change from debug to warning level)
• Make CVE query prefix case-insensitive in website/views/issue.py for better UX

[Pritz395]

/assign

[github-actions]

  🚫 **Please do not create new issues**  
  We currently have **many open issues** to focus on, some even with $5 bounties.
  
  If you believe your issue is important and should be solved,  
  please create a new topic in the BLT forum page instead.  
  Thanks for understanding! 🙏

[github-actions]

Hello @Pritz395! You've been assigned to OWASP-BLT/BLT issue #5286. You have 24 hours to complete a pull request.

---

This comment was generated by OWASP BLT-Action

[Pritz395]

@coderabbitai verify this is not a conflicting issue

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash

# Fetch details of issue #5286
echo "=== Issue #5286 Details ==="
gh issue view 5286 --json number,title,body,state,labels,author

# Search for similar issues (open issues only)
echo -e "\n=== Searching for potentially similar open issues ==="
gh issue list --state open --limit 100 --json number,title,body,state,labels

Length of output: 84319

---

@Pritz395 I've verified issue #5286 and it is NOT a conflicting issue. Here's my analysis:

Issue #5286 Summary

• Title: Improve error handling: Remove exception details from API responses
• Status: CLOSED ✅
• Focus: Information disclosure through raw exception messages in API responses

Verification Results

After reviewing all open issues in the repository, I found:

✅ No conflicts - No other open issues address:

• Removing exception details from API error responses
• The specific files mentioned (repo.py, bitcoin.py, core.py, organization.py)
• Information disclosure through error messages in the same context

Similar but Non-Conflicting Issues

While I found these security-related issues, they address different concerns:

• Remove GET based actions that make server side changes. #4058 - CSRF vulnerabilities (GET-based state changes)
• Show an error message on incorrect login credentials and fix verify email page UI. #4056 - Login form error messages (not API exceptions)

Conclusion

Since this issue is already CLOSED and addresses a unique concern (API exception handling for information disclosure) that no other open issue covers, there are no conflicts. You're clear to work on any related tasks! 🎉