T09 · Insecure Skill Coding Practices
- Location
scripts/search-user.js:8- Finding
Hardcoded Feishu Application Credentials
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This Feishu messaging skill is mostly purpose-related, but it ships executable scripts with hardcoded Feishu credentials and under-disclosed directory/profile access.
Review before installing or running. The publisher should remove and rotate the embedded Feishu secrets, require explicit user-provided least-privilege credentials, document contact-directory and upload permissions, and avoid printing employee PII or credential fragments. Do not run the bundled scripts against a real tenant unless you understand exactly which Feishu app and permissions they will use.
scripts/search-user.js:8Hardcoded Feishu Application Credentials
scripts/search-user.js:50Undeclared Employee Directory Access and PII Disclosure
scripts/test-send-message.js:127Application Secret and Access Token Fragments Logged to Standard Output
The skill advertises document creation, group/member lookup, and retry behavior, but the examples do not fully implement that stated workflow and instead resemble direct API test snippets. In a security context, inaccurate capability descriptions reduce informed consent and can hide the true operational scope of external actions such as sending messages or uploading content.
The skill advertises document creation, group/member lookup, and retry behavior, but the examples do not fully implement that stated workflow and instead resemble direct API test snippets. In a security context, inaccurate capability descriptions reduce informed consent and can hide the true operational scope of external actions such as sending messages or uploading content.
The skill advertises document creation, group/member lookup, and retry behavior, but the examples do not fully implement that stated workflow and instead resemble direct API test snippets. In a security context, inaccurate capability descriptions reduce informed consent and can hide the true operational scope of external actions such as sending messages or uploading content.
The script embeds a Feishu APP_SECRET directly in source code and uses it to obtain tenant access tokens for authenticated API calls. Hardcoded secrets are highly likely to leak through source control, logs, package distribution, or developer workstation access, allowing unauthorized parties to impersonate the application and send messages or access tenant-scoped APIs.
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
try {
// 获取 token
console.log('📝 获取 access token...');
const token = await getTenantAccessToken();
console.log(`✅ Token 获取成功\n`);
The skill contains code examples that rely on environment-backed or external credentials and interact with external APIs, but the manifest does not declare any explicit tool scope, permissions, or allowed-tools boundaries. This creates an authorization and review gap where an agent could invoke broader capabilities than users or operators expect, increasing the risk of unintended data access or message transmission.
The manifest frames the skill as a messaging workflow, while the body expands into broader resource management including file and image upload. That discrepancy can mislead users into approving a narrower capability set than the skill effectively supports, which is especially risky because uploads can exfiltrate local or user-provided data to an external service.
The skill describes actions that send messages, upload content, and enumerate group membership, but it does not warn users that their text, files, or contact/group data will be transmitted to Feishu. This lack of transparency can lead to privacy violations, accidental disclosure of personal data, and misuse of directory information.
Image and file upload functions materially increase the data-exfiltration surface beyond basic text messaging, yet they are not justified or bounded by the stated purpose. In an agent setting, undocumented upload capability is dangerous because users may unknowingly authorize transmission of sensitive local content to Feishu.
The script embeds default Feishu APP_ID and APP_SECRET values directly in source code, causing sensitive credentials to be exposed to anyone with repository or artifact access. Hardcoded secrets are a serious issue because they can be reused to obtain tenant tokens and access protected API functionality outside intended controls.
This code obtains a tenant access token using app credentials and then sends a user-provided name to Feishu search APIs, but the only visible logs announce progress rather than disclose that credentials and personal query data are being transmitted to an external service. Under the code-file criteria, network calls that transmit user or system data should have some user disclosure unless the action is clearly documented as the skill's stated purpose, which is not established within this file beyond a brief Chinese comment.
The script performs user-directory search and then retrieves detailed user profiles, which goes beyond a narrowly defined messaging workflow and expands access to organizational identity data. In this skill context, that increases privacy and data-minimization risk because a messaging helper only needs the minimum identity attributes required to identify a recipient, not broad profile enrichment.
The script prints personal attributes including employee number, email, mobile number, and department IDs to the console, which is unnecessary for simply sending a message. This creates avoidable exposure of personally identifiable information and increases the chance of leakage through terminal history, logs, screenshots, or downstream tooling.
The script sends recipient identifiers and message content to Feishu over HTTPS, which is a network operation involving user or system data. While it logs that it is about to send a test message, it does not clearly warn the user that provided IDs and content will be transmitted to an external service under the app's credentials.
The script sends an app ID, app secret, access token request, recipient ID, and message content to an external service, and it even embeds a default secret in code. In a messaging skill this network transmission is expected, but the hardcoded fallback secret and lack of explicit operator warning/consent increase the risk of credential leakage and unintended disclosure of message content.
The manifest describes a Feishu messaging skill for sending messages, finding group members/IDs, and retrying failed sends. This file adds a separate capability to call the user_info endpoint and read current-user profile data, which is not justified by the stated purpose of sending messages and is not used by the script's actual send flow.
SQP-3 applies to all file types and includes language policy violations. The manifest description and user-facing instructions are presented only in Chinese, which can impose a language constraint on users without opt-in or justification.
Comments, status messages, and error strings are presented only in Chinese, forcing a specific language for users without opt-in or justification. The policy for natural-language violations applies to all file types and allows locale constraints only when documented and justified or when users are given a choice.
User-facing strings are entirely in Chinese and timestamps are forced to use the 'zh-CN' locale via toLocaleString('zh-CN'). This imposes a specific language and locale on all users without opt-in or explanation, which matches the language/locale policy concern.
The inline comment for step 2 says '获取当前用户信息(用 app_access_token)', but the code only fetches a tenant access token and prints usage guidance; it never calls getMe or retrieves user information. This is an active contradiction between the comment/documentation and runtime behavior, not just an omission.
The script hard-codes the 'zh-CN' locale in toLocaleString for generated message and output timestamps. This imposes a specific language/locale choice rather than offering a user-selected or environment-based locale, which matches the policy violation category for locale constraints.
No suspicious patterns detected.