T09 · Insecure Skill Coding Practices
- Location
SKILL.md:15- Finding
Authentication Is Disabled by Default for Sensitive Health and Administrative APIs
- Content
View full analysis
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: HighThe 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-keyUnauthenticated data initialization:
bash curl -X POST http://localhost:8090/api/seedA 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_REVIEWcan 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
View 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-keyandreviewer-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
401responses and unauthorized roles receive403responses.