T09 · Insecure Skill Coding Practices
- Location
SKILL.md:47- Finding
Potential Exposure of Sensitive Feishu API Data Through Verbose Logging
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 47, 64-68, 89, 110-114, 136, 155-159, 181, 202-206, 228, and 244-248
Vulnerability Type: Sensitive data exposure through debug and unrestricted response logging
Risk Level: MediumVulnerable Code
The examples enable SDK debug logging in every API client:
python .log_level(lark.LogLevel.DEBUG) \Failed API responses are written to logs without redaction:
python lark.logger.error( f"client.im.v1.chat.search failed, code: {response.code}, msg: {response.msg}, log_id: {response.get_log_id()}, resp: {json.dumps(json.loads(response.raw.content), indent=4, ensure_ascii=False)}")Complete successful API response objects are also logged:
python lark.logger.info(lark.JSON.marshal(response.data, indent=4))Equivalent logging patterns are repeated in the message creation, image upload, file upload, and group-member retrieval examples.
Technical Analysis
The Skill instructs users to enable the Feishu SDK's
DEBUGlog level while also explicitly logging complete successful and failed API responses. These responses can contain user identifiers, chat identifiers, member records, message metadata, uploaded-file metadata, diagnostic details, and other tenant-specific information.Debug-level SDK output may additionally expose HTTP request or response details beyond those explicitly logged by the examples. Because the response content is serialized without field filtering or redaction, any sensitive values returned by the API can be copied into terminal output, CI logs, agent transcripts, or centralized logging platforms.
Exploitation requires access to logs generated by an authenticated execution. This issue does not independently grant additional Feishu privileges; it exposes information already available to the configured application and returned by the invoked API.
Attack Path
- A user copies or executes on ...[truncated 1301 chars]
- Remediation
View remediation
Remediation Suggestions
- Change the default SDK log level from
DEBUGtoINFO,WARNING, orERROR. - Permit debug logging only through an explicit, temporary troubleshooting option that is disabled by default.
- Do not log
response.raw.contentor serialize completeresponse.dataobjects. - Log only the minimum operational fields required, such as the API operation, result status, error code, and request or log identifier.
- Apply centralized redaction for user IDs, chat IDs, message content, file metadata, authorization headers, tokens, and tenant-specific fields.
- Restrict access to application and CI logs, define short retention periods, and prevent logs from being included in public build artifacts or agent transcripts.
- Add tests or linting rules that detect debug logging and unrestricted serialization of API responses.
- Replace the fixed example user and chat identifiers with clearly marked placeholders to reduce the chance of accidental operations against unintended resources.
- Change the default SDK log level from
