T09 · Insecure Skill Coding Practices
Error
- Location
recognize.py:104- Finding
Hardcoded API credential exposed and automatically used as a fallback
- Content
View full analysis
" config["headers"]["Authorization"] = f"Bearer {config['api_key']}" ``` The original source contains a complete credential-shaped value in place of ``. It is redacted here to avoid further disclosure. `usage-guide.md:43-47`: ```python api_key = "" headers = { "Authorization": f"Bearer {api_key}", "Content-Type": "application/json" } ``` The same complete credential is present in the original documentation. ### Technical Analysis The project embeds a bearer credential directly in executable source code and duplicates it in public usage documentation. Anyone who obtains the Skill package can retrieve the credential without authentication. The executable does not merely include the credential as an inactive example. `get_model_config()` automatically selects it whenever neither `IMAGE_MODEL_API_KEY` nor a usable credential in `~/.openclaw/openclaw.json` is found. The credential is then placed in the `Authorization` header and sent to the DashScope endpoint. The configuration instructions increase the likelihood of unintended fallback. `README.md:12-17` documents `BAILIAN_API_KEY`, while the implementation reads `IMAGE_MODEL_API_KEY` at `recognize.py:40-41`. A user following the README can therefore believe that a private key has been configured while the application silently uses the embedded shared key instead. Hardcoded credentials violate secret-isolation principles because they cannot be distributed, rotated, audited, or revoked independently of the application package. ### Attack Pat ...[truncated 1606 chars]- Remediation
View remediation