Typefully API Error Handling Exposes Sensitive Internal Data to End Users

A low-severity but persistent information disclosure vulnerability has been identified in the Typefully API integration, where raw error responses are directly exposed to users. The flaw, located in the `src/services/typefully.ts` file, fails to sanitize API error messages before they are thrown, potentially leaking sensitive internal data such as API rate limits, internal identifiers, and implementation details directly into user-facing logs and error reports.

The vulnerability stems from a direct error-throwing pattern in the code. When the API call fails, the system captures the full text of the error response and includes it verbatim in a thrown `Error` object. This means any sensitive debugging information, system status, or operational limits returned by the Typefully backend could be displayed to an end user or captured in third-party error monitoring services. While the immediate risk is classified as low, the exposure creates a tangible information leak that could aid malicious actors in profiling system behavior or timing attacks.

The recommended fix involves implementing a sanitization layer. Instead of passing the raw error text, the code should catch specific HTTP status codes—like a 401 Unauthorized—and throw a generic, user-safe error message. This practice is a fundamental security control for third-party API integrations, preventing accidental data exposure and hardening the application's external attack surface. The persistence of such a flaw highlights a common oversight in development workflows where error handling is treated as a functional rather than a security concern.