T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:37
- Finding
- Hard-Coded Recipient May Receive Unauthorized Access to Generated Reports## Vulnerability Details **File Location**: `SKILL.md:37` **Vulnerability Type**: Hard-coded document-sharing recipient **Risk Level**: Medium ### Vulnerable Code ```sh 4. Share with stakeholders: `gws drive permissions create --params '{"fileId": "DOC_ID"}' --json '{"role": "reader", "type": "user", "emailAddress": "cfo@company.com"}'` ``` ### Technical Analysis The recipe directs the agent to grant a hard-coded email address reader access to the generated Google document. Sharing is performed without requiring user confirmation or verifying that `cfo@company.com` is an authorized recipient for the current organization, source spreadsheet, or report. This behavior exceeds the core report-generation operations of reading spreadsheet data and creating a document. Because the report may contain business information derived from a Google Sheet, automatically granting access to a fixed account can cause unauthorized disclosure when the recipe is used outside the environment for which that address was intended. ### Attack Path 1. A user invokes the recipe to produce a report from a Google Sheet. 2. The agent reads spreadsheet data that may contain confidential business information. 3. The agent creates and populates a Google document with that information. 4. Following the final recipe step, the agent invokes the Google Drive permissions API. 5. Reader access is granted to the hard-coded `cfo@company.com` account without recipient validation or user confirmation. 6. If that account is not authorized for the user's data, its owner can access the generated report. ### Impact Assessment The recipient obtains reader access to the generated Google document. This does not grant broader system or Google Drive privileges, but it can expose all information included in that report, such as sales figures, revenue data, customer names, and other spreadsheet-derived content. The scope is limited to documents shared through this instr ...[truncated 87 chars]
- Remediation
- ## Remediation Suggestions - Remove automatic sharing from the default report-generation workflow. - Replace the hard-coded address with an explicit parameter such as `STAKEHOLDER_EMAIL`. - Require the user to confirm the exact recipient address and permission role immediately before creating the permission. - Validate that the recipient belongs to an approved domain or allowlist where organizational policy requires it. - Display the target document ID, recipient, and access level for review before executing the sharing command. - Apply least privilege by using `reader` access unless the user explicitly requests and authorizes a stronger role. - Permit report generation to complete without sharing when no authorized recipient is supplied. - Record or return the resulting permission details so the user can verify and revoke access if necessary. A hardened example should use a user-supplied, validated value rather than a fixed account: ```sh gws drive permissions create \ --params '{"fileId": "DOC_ID"}' \ --json '{"role": "reader", "type": "user", "emailAddress": "STAKEHOLDER_EMAIL"}' ```