What Caused a Google Apps Script Breach? Postmortem (SC.L2-3.13.13)

The breach was caused by an employee authorizing and deploying an unreviewed Google Apps Script that used overly broad Google Drive permissions, executed through an installable trigger, and sent file content to an external endpoint. This google apps script breach postmortem found that the organization had neither an enforceable mobile-code authorization process nor monitoring capable of correlating Apps Script executions, OAuth scope grants, Drive access, and outbound activity. For NIST SP 800-171 Rev. 2 and CMMC 2.0 Level 2, the failure mapped directly to SC.L2-3.13.13: the organization did not control or monitor mobile code.

This composite incident is based on recurring Google Workspace investigation patterns and is written for internal auditors preparing evidence before an external assessment. Names, dates, and file counts have been changed, but the control failure, evidence gaps, and corrective actions are representative.

What happened during the incident?

The affected organization used Google Workspace Business Plus for collaboration and stored controlled technical data in shared drives. Its engineering operations team relied on Google Sheets and Google Apps Script to automate intake forms, project status reports, and document routing. Although the organization had a general acceptable-use policy, it had not defined Apps Script as mobile code, identified authorized use cases, or required review before scripts were granted OAuth scopes.

An engineering coordinator copied a public Google Sheets template that included a bound Apps Script project. The visible spreadsheet functionality was benign: it generated weekly status summaries and emailed reminders. The copied script also contained an installable trigger that ran after edits and requested permissions to view and manage files in Google Drive. After authorization, the script used those permissions to enumerate accessible files, copy selected document content, and transmit encoded data through an HTTPS request to an attacker-controlled service.

What was the incident timeline?

What does this google apps script breach postmortem establish about root cause?

The immediate technical cause was an unapproved script receiving broad OAuth authorization and running under a legitimate employee identity. The more important root cause was governance: the organization treated Apps Script as a convenient productivity feature rather than mobile code capable of executing logic, accessing cloud data, creating triggers, and communicating with external services.

The copied script had not exploited a Google Workspace vulnerability. It operated through permissions granted during the consent process. Its access was effective because the coordinator belonged to several shared-drive groups and could read more material than was necessary for the spreadsheet’s stated purpose. The script’s installable trigger further reduced visibility because it could execute after later spreadsheet edits without the user consciously launching it.

Investigators identified four contributing conditions:

• No authorization inventory: The organization could not produce a list of approved Apps Script projects, owners, business purposes, OAuth scopes, triggers, or external destinations.
• No scope-review requirement: There was no control requiring business owners or security personnel to assess whether a script needed https://www.googleapis.com/auth/drive rather than a narrower scope.
• Excessive data access: Shared-drive membership was assigned for operational convenience, allowing the coordinator account to access controlled documents unrelated to the status-tracking process.
• Fragmented monitoring: Drive logs existed, but the security team had no detection logic for high-volume document reads initiated by an Apps Script authorization, and no process to review script triggers or source code.

This Apps Script breach also exposed an evidentiary problem. The organization could demonstrate that Google Workspace logging was enabled, but it could not demonstrate that someone routinely reviewed relevant mobile-code activity or that anomalous activity would generate remediation. For an assessor, enabled logs without an operational monitoring process are not persuasive evidence that SC.L2-3.13.13 is functioning.

Why did SC.L2-3.13.13 fail in practice?

SC.L2-3.13.13 requires an organization to control and monitor mobile code. The organization failed both objectives. Its policies addressed software installed on endpoints but did not define cloud-hosted automation, bound scripts, installable triggers, or OAuth-authorized scripts as mobile code subject to approval. As a result, the coordinator’s action was not technically prohibited, routed for approval, or measured against documented restrictions.

The technical configuration also did not support the policy intent. Google Workspace Apps Script remained available to all users, including users handling controlled technical data. The organization had not used organizational units to limit Apps Script access to approved business groups, nor had it established a separate approval path for higher-risk scripts requiring Drive-wide access, external HTTP requests, or triggers.

Monitoring failed because the security team looked at individual data sources in isolation. Google Drive audit logs showed the employee identity reading files, which was not inherently suspicious. The Apps Script project was not included in the asset inventory, and no reviewer examined whether scripts were using services such as DriveApp, UrlFetchApp, or installable triggers. The resulting Google Apps Script incident was therefore visible only after a user noticed abnormal behavior.

What corrective and preventive actions were implemented?

Containment began with revocation and preservation. Security disabled the affected account, revoked Google sessions and OAuth tokens, removed the installable trigger, transferred ownership where needed, and preserved the spreadsheet, script source, execution history, Drive audit records, and administrator actions. The incident team also reviewed the user’s accessible shared drives, rotated credentials stored in affected documents, notified data owners, and completed contractual and incident-reporting analysis.

The corrective program then focused on making mobile-code decisions auditable rather than merely cautionary.

• Defined mobile code: The revised policy explicitly includes Google Apps Script, bound and standalone scripts, triggers, Workspace add-ons, macros, browser-executed code, and cloud automation that can execute with organizational credentials.
• Established authorization records: Each approved script now has an owner, business purpose, data classification, approved OAuth scopes, trigger type, external service destination, approver, review date, and retirement date in the configuration management repository.
• Restricted Apps Script by organizational unit: Apps Script access was disabled for workforce groups without a justified need and retained only for designated automation and engineering organizational units. Exceptions require documented approval from the system owner and security.
• Required source and scope review: Scripts requesting broad Drive scopes, Gmail access, external HTTP requests, or installable triggers must undergo security review before deployment. Reviewers inspect source code, manifest settings, trigger behavior, data destinations, and ownership.
• Reduced shared-drive exposure: Data owners recertified group membership and removed broad access that was unrelated to job responsibilities, limiting the impact of authorized identities and authorized scripts.
• Added monitoring procedures: The security operations team now reviews Google Workspace Drive audit events, administrator changes, OAuth-related events, and script inventory changes. High-volume reads, unusual file copies, new triggers, and scripts with external network functions are investigated under a documented playbook.

The audit evidence package was designed around the two key objectives of SC.L2-3.13.13. It includes the mobile-code policy, approved-script register, Google Admin console organizational-unit settings, quarterly script-owner attestations, samples of security reviews, log-review tickets, incident playbooks, and remediation records. This matters because an assessor should be able to trace an approved script from policy authorization through technical restriction, monitoring, and periodic review.

What lessons generalize from this Google Workspace incident?

• Cloud automation is code execution, not just collaboration. A script attached to a spreadsheet can access data and act with an employee’s delegated permissions. Treating it as harmless office automation creates a control blind spot.
• User authorization is not organizational authorization. A Google consent screen proves that a user clicked allow; it does not prove that the organization approved the business use, scope, trigger, or external destination.
• Least privilege must apply to both identities and scripts. Narrowing shared-drive access and OAuth scopes limits the damage when a script is malicious, compromised, or simply poorly designed.
• Monitoring must connect context. Drive reads are difficult to interpret without knowing whether a script ran, which script owned the action, what scopes it held, and whether it contacted an external service.
• Evidence must show operation over time. A policy and a one-time configuration screenshot do not prove compliance; recurring reviews, exception approvals, alerts, investigations, and closure records demonstrate that mobile-code controls are operating.

Before your external assessment, perform a targeted review of every authorized Google Apps Script project, trigger, scope, owner, and monitoring record against SC.L2-3.13.13, then document and remediate every unauthorized or unmonitored exception.