T09 · Insecure Skill Coding Practices
Error
- Location
- SKILL.md:15
- Finding
- Authentication Is Disabled by Default for Sensitive Health and Administrative APIs## Vulnerability Details **File Location**: `SKILL.md`, lines 15-22, 32-34, 55-98, and 126 **Vulnerability Type**: Missing authentication and insufficient privilege separation **Risk Level**: High The documentation states that authentication is disabled by default while describing endpoints that create health records, submit and approve intervention plans, initialize data, expose audit information, and modify medication-review rules. Relevant configuration: ```bash export HEALTH_GIT_BASE_URL=http://localhost:8090 export AUTH_ENABLED=true export CONSUMER_API_KEY=consumer-key export REVIEWER_API_KEY=reviewer-key ``` Unauthenticated data initialization: ```bash curl -X POST http://localhost:8090/api/seed ``` A privileged rule update is also demonstrated without an API key: ```bash curl -s -X PATCH http://localhost:8090/api/rules/MEDICATION_CHANGE_REVIEW \ -H "Content-Type: application/json" \ -d '{"config_json":{"keywords":["increase medication","new drug","double dose","insulin","adjust dose"]}}' ``` ### Technical Analysis Authentication must be enabled by default for an application that processes health activity, medication-related information, intervention plans, review decisions, outcomes, and audit events. Binding the service to localhost reduces network exposure but is not an authorization boundary. Other processes running in the same environment can connect to the service, and the API could also become reachable through container port publishing, reverse proxies, development tunnels, or an altered server binding. The rule-management endpoint is particularly sensitive. Changing `MEDICATION_CHANGE_REVIEW` can alter which medication-related plans are blocked for human review. The example does not provide an administrator or reviewer credential, indicating that the documented default configuration does not enforce least privilege for this operation. The documented reviewer key is also a predictable ...[truncated 1745 chars]
- Remediation
- ## Remediation Suggestions - Enable authentication by default and require an explicit development-only option to disable it. - Require authorization on every endpoint, including read-only dashboard, metrics, events, and rules endpoints. - Implement role-based access control with separate consumer, reviewer, and administrator roles. - Restrict rule creation and modification to a narrowly scoped administrator role. - Require reviewer authorization for review and merge operations, and verify that reviewers cannot approve their own requests where separation of duties is required. - Replace example keys with instructions for generating high-entropy secrets. Reject documented defaults such as `consumer-key` and `reviewer-key`. - Store secrets outside source files and command history, rotate them periodically, and support revocation. - Bind explicitly to the loopback interface for development. Document that port forwarding, public binding, and reverse proxies require TLS and production authentication. - Add request-origin and CSRF protections if browser-based clients can access the API. - Validate and constrain rule updates using a schema, immutable rule identifiers, safe minimum conditions, and administrator approval. - Write tamper-resistant audit records for authentication failures, review decisions, and safety-rule changes. - Add automated tests proving that unauthenticated requests receive `401` responses and unauthorized roles receive `403` responses.