Security Audit
moodle-external-api-development
github.com/davila7/claude-code-templatesTrust Assessment
moodle-external-api-development received a trust score of 88/100, placing it in the Mostly Trusted category. This skill has passed most security checks with only minor considerations noted.
SkillShield's automated analysis identified 4 findings: 0 critical, 0 high, 1 medium, and 2 low severity. Key findings include Network egress to untrusted endpoints, Covert behavior / concealment directives, Insecure logging example in rubric.
The analysis covered 4 layers: Manifest Analysis, Static Code Analysis, Dependency Graph, LLM Behavioral Safety. All layers scored 70 or above, reflecting consistent security practices.
Last analyzed on February 11, 2026 (commit 458b1186). SkillShield performs automated 4-layer security analysis on AI skills and MCP servers.
Layer Breakdown
Behavioral Risk Signals
Security Findings4
| Severity | Finding | Layer | Location | |
|---|---|---|---|---|
| MEDIUM | Network egress to untrusted endpoints HTTP request to raw IP address Review all outbound network calls. Remove connections to webhook collectors, paste sites, and raw IP addresses. Legitimate API calls should use well-known service domains. | Manifest | cli-tool/components/mcps/devtools/figma-dev-mode.json:4 | |
| LOW | Covert behavior / concealment directives Multiple zero-width characters (stealth text) Remove hidden instructions, zero-width characters, and bidirectional overrides. Skill instructions should be fully visible and transparent to users. | Manifest | cli-tool/components/mcps/devtools/jfrog.json:4 | |
| LOW | Insecure logging example in rubric The `log_debug` function example provided in the rubric writes the `$message` parameter directly to a file without explicit sanitization. If a developer were to adopt this example and pass untrusted, user-controlled input to this function, it could lead to several vulnerabilities within the Moodle environment: 1) Data Exfiltration: Sensitive data present in the `$message` could be written to disk. 2) Command Injection/Path Traversal: If `$message` contains path traversal characters (e.g., `../../`), it could allow writing to arbitrary files on the server. The rubric does not provide guidance on sanitizing log messages or avoiding logging sensitive information, which is a missed opportunity for secure development guidance. Add guidance to sanitize log messages, especially if they contain user-controlled input, and to explicitly warn against logging sensitive data. For example, suggest using Moodle's built-in logging API or ensuring that only trusted, non-sensitive data is logged after appropriate sanitization. | LLM | SKILL.md:199 | |
| INFO | Example shows hardcoded credentials The `curl` example provided for testing the API demonstrates how to obtain a token using hardcoded `username=admin` and `password=yourpassword`. While this is an example for demonstration purposes within a rubric, it sets a poor security precedent by showing credentials directly in a command. This could inadvertently encourage developers to hardcode credentials in their own scripts or expose them in logs, leading to credential harvesting or unauthorized access in real-world scenarios. Replace hardcoded credentials with clear placeholders like `YOUR_USERNAME` and `YOUR_PASSWORD`. Add a prominent note advising against hardcoding credentials in production environments and suggest using secure methods for credential management (e.g., environment variables, secret management systems). | LLM | SKILL.md:341 |
Scan History
Embed Code
[](https://skillshield.io/report/052b0ec9d7838b92)
Powered by SkillShield