Analysis of Exposed Secrets in Enterprise Apps Script Code

‍

What We Found in 35,000 Apps Script Projects

Our comprehensive analysis of 35,000 Google Apps Script projects across enterprise environments revealed a concerning pattern that puts organisational data at significant risk: the widespread practice of embedding sensitive credentials directly in code.

‍

Types of Exposed Secrets

When examining the codebase, we found several categories of exposed credentials:

‍

API Keys
Developers frequently hardcoded API keys directly in their script files, often in clearly labeled variables such as:

‍
_{// Google Maps API Key - provides access to mapping services across applications
const API_KEY = "AIzaSyDj8fzjkasd7Jjkad7JHGhad6";}

_{// Google Analytics tracking identifier
const ANALYTICS_KEY = "UA-12345678-1";}

_{// JIRA integration API key
const JIRA_API_KEY = "NPTb572ExTRVMJTVBACxD5D4";}

‍

These keys provide access to various external services including data providers, and cloud services. When exposed, they can allow unauthorised users to make authenticated API calls as if they were your organisation.

‍

OAuth Tokens

OAuth tokens were commonly found stored in plain text within script files:

_{const ACCESS_TOKEN = "ya29.a0AfB_byC...";
const REFRESH_TOKEN = "1//04dX...";}

‍

These tokens often had extensive permissions to access organizational resources including Drive documents, Gmail, Calendar, and other Google Workspace services. In many cases, these tokens had no expiration date configured.

‍

Service Account Credentials

We discovered numerous instances where developers had copied entire service account JSON credential files directly into code:

_{const serviceAccountCreds = {
 "type": "service_account",
 "project_id": "company-project-123456",
 "private_key_id": "abcdef123456...",
 "private_key": "-----BEGIN PRIVATE KEY-----\nMIIEvgIBADANBgkqhkiG9w0BAQEF...",
 "client_email": "service-name@company-project-123456.iam.gserviceaccount.com",
 "client_id": "123456789012345678901",
 ...
};}

‍

These credentials often had broad permissions across Google Cloud services and represented a significant security risk. Service account keys typically never expire unless manually revoked.

‍

Database Connection Strings

Complete database connection strings with embedded credentials appeared in many projects:

const DB_CONNECTION = "postgres://username:password@database.company.com:5432/production_db";


‍

These strings provided direct access to organizational databases, often with elevated privileges.

‍

The Security Implications

The exposure of these credentials creates several serious security vulnerabilities:

1. Unauthorized Access: Anyone with read access to the Apps Script project can extract these credentials and use them outside of the intended application. This includes:
  - Other developers within your organization
  - External contractors with temporary access
  - Users with whom the script has been shared

2. Credential Persistence: When credentials are embedded in code, they often remain there long after the original developer has moved on. We found instances of active credentials in projects that hadn't been modified in over three years.

3. Access Beyond Intended Scope: Many of the exposed credentials had permissions far beyond what was needed for the specific application, creating a significant risk of lateral movement if compromised.

4. Audit Trail Challenges: When credentials are shared through code, it becomes nearly impossible to attribute actions to specific individuals, as multiple people may be using the same credential.

‍

Why This Happens

Our analysis revealed several common reasons why developers embed credentials in their code:

1. Development Convenience: Hardcoding credentials is simpler during the development process than implementing proper secret management.

2. Limited Knowledge: Many Apps Script developers are not security specialists and may not understand the risks associated with credential exposure.

3. Lack of Clear Alternatives: The Apps Script environment doesn't provide obvious built-in solutions for secret management.

4. Time Pressure: Developers under deadline pressure often choose the fastest implementation path.

‍

Secure Alternatives

Instead of embedding credentials directly in code, developers should consider these more secure approaches:

1. Using Apps Script Properties Service: Store sensitive values in the Properties Service, which provides a more secure way to manage configuration data:

_{// Instead of hardcoding:
const API_KEY = "a1b2c3d4e5f6g7h8i9j0...";}

_{// Store the key once using:
PropertiesService.getScriptProperties().setProperty('API_KEY', 'a1b2c3d4e5f6g7h8i9j0...');}

_{// Then access it in code using:
const apiKey = PropertiesService.getScriptProperties().getProperty('API_KEY');}

‍

2. Implementing OAuth Properly: Use the OAuth2 library with proper token storage and refresh mechanisms instead of hardcoded tokens.

3. Using Environment Variables: For containerized Apps Script projects, leverage environment variables instead of hardcoded values.

4. Implementing Secret Rotation: Establish processes to regularly rotate credentials used by applications.

‍

Next Steps for Organisations

Based on our findings, we recommend these actions to address exposed secrets:

1. Immediate Credential Review: Conduct a comprehensive review of all Apps Script projects to identify and remediate exposed credentials.

2. Developer Education: Provide training on secure credential management specifically for Apps Script developers.

3. Automated Scanning: Implement continuous monitoring tools that can detect newly introduced credentials in code.

4. Security Guidelines: Establish clear guidelines for Apps Script development that prohibit hardcoded credentials.

5. Credential Rotation: Immediately rotate any credentials that have been exposed in code repositories.

‍

How Builtlist Simplifies Apps Script Governance

Managing thousands of Apps Script projects across an organisation is complex, but Builtlist makes it effortless with a structured, step-by-step approach:

1. Discover & Catalog – Builtlist automatically scans all Apps Script projects across your domain, providing a centralized inventory of scripts, their owners, usage patterns, and dependencies.

2. Assess & Identify Risks – Using Gemini, Builtlist performs automated code scans to detect exposed secrets, excessive permissions, and potential vulnerabilities in real time.

3. Alert & Prioritize – When a security issue is found, Builtlist notifies the relevant teams with clear insights on the affected projects, the severity of the risk, and recommended next steps.

4. Manage & Remediate – Security and Workspace teams can view vulnerabilities within Builtlist, with the ability to retest once project teams have remediated the vulnerability, and ensuring compliance with governance policies.

5. Optimize & Automate – Beyond security, Builtlist helps teams improve performance by identifying inefficient code and suggesting optimisations, ensuring that Apps Script automations run securely and efficiently.

‍

With Builtlist, organisations gain visibility into Apps Script management—no manual audits, no fragmented oversight, just a seamless, AI-powered solution that keeps your automations secure and optimised.

‍

By addressing these issues systematically, organisations can significantly reduce the risk posed by exposed credentials while still enabling developers to build powerful Apps Script solutions.

‍