T09 · Insecure Skill Coding Practices
- Location
douyin-uploader.js:400- Finding
Chromium Is Launched with Browser Sandboxing Disabled
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This Douyin uploader is purpose-aligned but needs review because it can automatically publish to a public account while retaining local login state and launching Chromium with sandboxing disabled.
Install only if you are comfortable with an agent-controlled tool posting to your Douyin account by default. Prefer using --no-publish unless you intentionally want immediate publication, keep the skill directory private, do not commit douyin-cookies.json or chrome-user-data, run it as an unprivileged user, and review/pin dependencies before use.
douyin-uploader.js:400Chromium Is Launched with Browser Sandboxing Disabled
douyin-uploader.js:29Persistent Browser Authentication Profile Is Not Explicitly Permission-Hardened
package.json:31Dependency Installation Is Not Reproducibly Locked
The skill uses 'shell' capability that is not listed in its permissions. This may indicate deceptive intent or missing permission declarations.
The code saves live Douyin session cookies to a local JSON file, creating a reusable bearer token for account access if the file is stolen by another local user, malware, or a later-compromised process. Although permissions are tightened to 0600, there is no explicit just-in-time user consent or strong protection such as encryption or OS credential storage, so session theft remains plausible.
The uploader proceeds to click the publish button automatically whenever autoPublish is not set to false, without a final confirmation step showing the exact content being released. Because publishing is an externally visible, hard-to-reverse action, automation mistakes, bad inputs, or misuse by another caller can cause unintended public posting from the user's account.
The code presents natural-language user interaction text such as SMS verification notices and input prompts only in Chinese. This imposes a fixed language on users without opt-in or a locale-selection mechanism, which matches the policy's language/locale violation criteria.
This code includes natural-language strings in Chinese for the script description and usage, indicating a fixed language choice. The file does not offer any language selection or explain a justified region-specific requirement, which can violate language/locale policy requirements.
The natural-language description prominently presents the skill as a Douyin-specific uploader and includes only Chinese-language wording for its user-facing capability summary. This may indicate a locale/language constraint without any explicit opt-in or alternative language choice, which can conflict with language/locale policy expectations.
Using a caret range for puppeteer allows installation of newer dependency versions that were not explicitly reviewed with this skill, which weakens build reproducibility and can unexpectedly introduce vulnerable or breaking releases. In an automation skill that drives a browser and may handle authenticated sessions, dependency drift modestly increases supply-chain risk.
"manage": "node scripts/manage.js"
},
"dependencies": {
"puppeteer": "^23.11.1"
}
}
Dependency has known vulnerabilities (CVEs). Using packages with unpatched security flaws exposes the environment to known exploits.
The file’s natural-language strings present the skill exclusively in Chinese (for example, the title and usage comment) without offering a language choice or documenting that the script is intentionally region-specific. Under the stated policy, forcing a specific language without user opt-in is a natural-language policy concern.
The file includes Chinese-only natural-language documentation for the script title, usage, and commands. Under the policy, forcing a specific language without user opt-in is a natural-language policy violation unless the locale restriction is clearly documented and justified, which is not present here.