T09 · Insecure Skill Coding Practices
Warning
- Location
- lib/attio_enhanced.py:105
- Finding
- Verbatim API Error Responses May Expose Sensitive CRM Data in Logs## Vulnerability Details **File Location**: `lib/attio_enhanced.py:105-117` and `lib/attio_enhanced.py:172-185` **Vulnerability Type**: Sensitive information exposure through logging **Risk Level**: Medium **Vulnerable code — synchronous request path:** ```python if response.status_code >= 400: error_text = response.text self.logger.error(f"Error response: {error_text}") # Create enhanced HTTPError with error body error = requests.exceptions.HTTPError( f"{response.status_code} {response.reason} | {error_text}", response=response ) error.error_body = error_text raise error ``` **Vulnerable code — asynchronous request path:** ```python if response.status >= 400: self.logger.error(f"Error response: {response_text}") # Create custom error with full details in the message error = aiohttp.ClientResponseError( request_info=response.request_info, history=response.history, status=response.status, message=f"{response.reason} | {response_text}" ) # Store error text as attribute for easier checking error.error_body = response_text raise error ``` ### Technical Analysis Both request implementations write the complete Attio API response body to the application logger whenever an HTTP error occurs. The same unredacted body is also inserted into exception messages and retained in the custom `error_body` attribute. Error responses from a CRM API may include rejected field values, email addresses, names, company information, record identifiers, validation context, or other business data. Logging these responses verbatim can copy sensitive information into console logs, CI output, centralized monitoring platforms, or long-retention log archives. This behavior also conflicts with the assertion in `README.md` that sensitive data is not logged. Although the authorization header itself is not ...[truncated 1443 chars]
- Remediation
- ## Remediation Suggestions 1. Do not log complete response bodies by default. Log only the HTTP status, request correlation ID, and a sanitized API error code. 2. Remove `error_text` from exception messages. Expose detailed response content only through an explicitly enabled diagnostic mode. 3. Implement a centralized redaction function that removes authorization values, email addresses, CRM field values, tokens, and sensitive identifiers before any response is logged. 4. If `error_body` must remain available programmatically, document it as sensitive and ensure upstream handlers do not serialize or log it automatically. 5. Limit diagnostic response size to prevent excessive or attacker-controlled log content. 6. Configure production logs with least-privilege access, encryption, retention limits, and audit controls. 7. Add tests confirming that representative personal data and token-like values never appear in log output or exception strings. 8. Correct the security documentation so that its logging claims accurately reflect the implementation.