A Study on Secret Exposure Cases within Vercel Environment Frontend Code: AWS, Stripe, Github Keys Were Exposed

1. Introduction: The Other Side of Development Speed – The Risk of Secret Exposure in Vercel Environments

Vercel: The Core Driving Force of Modern Web Development

Platforms like Vercel support easy building and deployment of frontends, maximizing development speed and convenience. Powerful features like serverless functions, edge networks, and Git integration improve the developer experience (DX), and by abstracting complex infrastructure management, they help developers focus on implementing core logic. Builds and deployments happen automatically with just a Git commit, allowing ideas to be quickly implemented as services.

Development Speed vs. Security Discipline: A Dangerous Imbalance

The maximization of development and deployment speed pursued by Vercel and others contributes to improving the developer experience, but it can also act as pressure to simplify security reviews or careful configuration check procedures. A speed-first approach can foster a culture that prioritizes feature releases over security, and the platform's advantages can paradoxically become indirect causes of security incidents.

Fatal Mistake: The Risk of Secrets Hidden in the Frontend

Behind this convenience lies a serious security risk where sensitive credential information ('Secrets') such as AWS Secret Keys, Stripe Secret Keys, database passwords, GitHub Personal Access Tokens (PATs), etc., are included in frontend JavaScript bundles due to developer mistakes or lack of knowledge, leading to exposure. Frontend code downloaded to the user's browser is effectively public information, and including Secrets in it is a very dangerous act corresponding to 'Secret Leakage' in the NHI OWASP Top 10.

Leaked Secrets can grant attackers unauthorized access rights to systems and data, potentially leading to serious consequences such as data leakage/manipulation, financial loss, API service abuse, etc.

Quantifying the State of Secret Exposure in Vercel Environments

This study was conducted to quantitatively determine how many dangerous Secrets are actually being exposed in environments hosted on Vercel. Through large-scale identification and filtering processes targeting actual operational sites, followed by in-depth analysis of frontend code, it was found that a significant number of various types of Secrets, including exploitable AWS and Stripe Secrets, were exposed. This report shares the research methodology, the discovered Secret exposure figures and types, potential risks, and practical measures for problem resolution and prevention.

The Combined Risk of Next.js Environment Variable Rules and Vercel Automatic Deployment

Vercel's fast development speed makes it easy to induce mistakes in areas requiring detailed settings and accurate understanding, such as environment variable processing. In particular, Next.js uses the NEXT_PUBLIC_ prefix rule before environment variable names to prevent client-side exposure. If a developer misuses this rule and mistakenly attaches the NEXT_PUBLIC_ prefix to a server-only Secret (e.g., AWS Secret Key), the risk greatly increases that during the Vercel build, the actual value of that Secret will be included in the client JavaScript bundle and immediately deployed to the production environment. When the convenient automatic deployment system and environment variable rules combine, developer carelessness or configuration errors can lead to serious Secret leakage incidents, demonstrating the existence of systemic risk factors where specific features of the platform and framework interact to amplify unintended risks.

2. Attack Surface Analysis: Identifying Vercel Hosting and Filtering Real Operating Environments

Anonymity of Shared Infrastructure and Difficulty of Exploration

Platforms like Vercel extensively use shared infrastructure such as Anycast IP addresses, making it difficult to find specific websites or a complete list of hosted sites. For example, Vercel's representative IP address 76.76.21.21 can host hundreds of thousands of domains. Complex DNS routing and IP address allocation are managed internally by the platform, making identification difficult with only single IP information.

Exploration Methodology: Complex Utilization of OSINT Techniques

To identify sites hosted on Vercel on a large scale, Open Source Intelligence (OSINT) techniques were utilized in combination. First, using Vercel's IP addresses (e.g., 76.76.21.21, 76.76.21.0/24) as starting points, tools like IPinfo.io, MxToolbox were used to collect large lists of mapped domains.

Second, based on the domains thus obtained, extensive subdomain exploration was performed using various tools such as SecurityTrails, OWASP Amass, Subfinder, crt.sh. These tools utilize various source information like Certificate Transparency logs, DNS records, web archives, etc. 

Finally, accuracy was increased by confirming Vercel's characteristic CNAME record (cname.vercel-dns.com) or specific A records (e.g., 76.76.21.21) in the collected list, and additionally searching for traces of Vercel or Next.js in HTTP response headers or source code.

Result: Identification of 40,000 Potential Hosts and Filtering of Approx. 6,000 Real Services for Analysis

Initially, a list of about 40,000 potential hosts was identified, but it included many targets that were not actually operational or were impossible to analyze, such as expired domains, discontinued projects, temporary preview deployments, and incorrect DNS settings. For the accuracy of the research results and practical risk assessment, among these, approximately 6,657 active domains that were actually valid and had a responding web server were filtered as the final analysis targets.

From an Attacker's Perspective, Shared Infrastructure is an Opportunity for Mass Exploration

The OSINT techniques used in this study are standard methods actually used by attackers for target system reconnaissance. The shared IPs or standard DNS patterns (cname.vercel-dns.com) of PaaS platforms like Vercel paradoxically provide attackers with opportunities to easily discover large numbers of potential attack targets. Attackers use automated tools to leverage these characteristics to identify Vercel-hosted websites on a large scale, and among them, can efficiently find active targets with vulnerabilities such as Secret leakage. The architecture design itself, intended for platform efficiency, ironically becomes an attractive large-scale attack vector exploration space.

3. Detection Techniques for Secrets Hidden within JavaScript Bundles and the Importance of Accuracy

JavaScript Bundle Analysis Process

For the filtered 6,657 active services, the frontend JavaScript files delivered to the end-user's browser were downloaded and analyzed in depth. Websites were automatically visited to extract and download .js file links, and browser automation utilizing the SeleniumBase library and Chrome DevTools Protocol (CDP) mode was performed to include dynamically loaded content.

Below is example code for reading the contents of Script files and document files via CDP mode.

Detection Technique: Limitations of Simple Pattern Matching and the Verification-Based Approach

In the past, detection primarily relied on regular expression (regex)-based pattern matching for known Secret formats (AWS keys, Stripe keys, etc.). However, this method has a very high false positive rate, posing a serious problem of incorrectly detecting strings that are not actual Secrets (Git commit hashes, UUIDs, etc.). This can induce alert fatigue, leading to real threats being missed.

This study adopted a verification-based approach that goes beyond simple pattern matching, utilizing tools such as Cremit's CLI tool to confirm the validity and potential behavior of discovered potential Secret strings. This can include sophisticated pattern matching, entropy analysis, context analysis, as well as active validation, which involves safely calling actual service (AWS, Stripe, etc.) APIs using the discovered key candidate to check its validity and permission scope. For example, upon discovering an AWS key candidate, AWS STS APIs (GetAccessKeyInfo, GetCallerIdentity) are called to check validity and permissions. By accurately identifying and reporting only valid Secrets that are actually exploitable through this process, time wastage and fatigue due to unnecessary false positives can be reduced, allowing focus on actual risks.

Secret scanning technology is evolving from simple detection to validation and context analysis. Considering the fast development environment and attackers' rapid exploitation attempts, the ability to quickly and accurately identify only 'actual risks' is important, and validity/permission verification is changing the core value of Secret scanning solutions from 'finding things' to 'verifying and prioritizing things'.

Utilized Tools and Technologies

Various open-source and commercial tools can be utilized for Secret detection, including Gitleaks, Yelp/detect-secrets, TruffleHog, Semgrep. GitHub, GitLab, etc., also provide their own Secret scanning features. Tools like JS Snitch are specialized for remote JavaScript scanning. These tools are often integrated into CI/CD pipelines or Git pre-commit hooks and utilized as preventive measures. This study, rather than relying on a specific tool, comprehensively considered various detection principles (pattern matching, entropy, keywords) and verification techniques, and utilized Cremit's service and CLI tool together for large-volume processing and programmatic access.

Accurate Secret detection directly impacts operational efficiency and security response speed. While time is spent handling false positives, actually leaked keys can be exploited by attackers. The ability to accurately identify only actual risks through validity verification is an essential element for effective threat response within a limited time.

4. Research Results: Analysis of Secret Exposure Status in Vercel Environments

Discovery: Confirmation of Actual Secret Leakage in 0.45% of 6,657 Sites

As a result of analyzing 6,657 actually operational Vercel-hosted services, it was confirmed that approximately 0.45% of the sites (30 sites) exposed valid Secret keys within their frontend code, possessing permissions for actual production environment usage or sensitive data access.

This 0.45% rate holds several important meanings. First, it reflects realistic risks targeting actual operational active services. Second, it means that within the analyzed sample alone (not the over 700,000 total Vercel host sites), 30 websites are exposed to serious security risks. Third, each leakage case can potentially lead to significant financial loss, data leakage, service interruption, etc., resulting in severe security incidents, so the impact upon occurrence can be very large. Finally, considering the detection/verification methodology used, it is a conservative estimate, and the actual scale of exposure could be larger. The frequency of occurrence may seem low, but considering the potential ripple effect of each leak, it is a risk that cannot be overlooked.

Types and Severity of Exposed Secrets

The types of Secrets discovered during the analysis process were very diverse, and the level of potential risk posed by each Secret also varied greatly. The discovered Secret types can be broadly classified into relatively low-value utility API keys and high-value important credentials.

Relatively low-value utility API keys include weather information providing APIs (e.g., OpenWeatherMap), IP address-based location information APIs (e.g., IPinfo.io), blockchain data lookup APIs (e.g., Etherscan API), etc. Leakage of these keys mainly causes temporary service disruptions due to exceeding usage limits of the corresponding third-party service, or can lead to slight additional cost issues if using usage-based billing policies. The possibility of directly connecting to serious security risks like data leakage or system takeover is relatively low, but management is still necessary as they can affect service availability.

On the other hand, high-value important credentials include GitHub tokens, AWS Secret Access Keys, Stripe Secret Keys (sk_live_...) or Restricted Keys (rk_live_...), etc., which are core risk factors. GitHub tokens grant access rights to personal or organizational code repositories, potentially leading to source code leakage, supply chain attacks through malicious code injection, CI/CD pipeline manipulation, etc., resulting in serious intellectual property loss and further security breaches.

AWS Secret Access Keys provide programmatic access rights to cloud infrastructure resources (EC2, S3, RDS, etc.), and depending on the IAM permission scope of the leaked key, possibilities range from simple S3 access to hijacking of entire cloud account management privileges, which can cause significant financial loss (e.g., cryptocurrency mining abuse) and data leakage or destruction.

Stripe Secret Keys or Restricted Keys grant powerful permissions to perform direct financial transactions (payments, refunds) through the Stripe account and access sensitive customer PII and payment data. Upon leakage, they can inflict fatal financial, legal, and reputational damage to business operations, such as fund theft through fraudulent transactions, mass leakage of customer data (legal liability, loss of trust), service interruptions, etc. Notably, even Restricted Keys (rk_live_), created with limited permission scope, can still perform sensitive tasks, making them very dangerous if exposed in the frontend.

These 'high-value important credentials' possess a fundamentally different dimension of risk compared to identifiers like AWS Access Key ID (AKIA...) or frontend-use Stripe Publishable Keys (pk_live_...). This study seriously addresses the leakage of AWS Secret Access Keys or Stripe Secret/Restricted Keys that should only be used on the server side.

Table 4.1: Summary of Discovered Secret Types

The discovery of 'High-Value/Critical' credentials indicates a need for serious security management improvement.

Normalization of Risk? Evidence of Lack of Security Awareness and Structural Problems

The fact that actual production environment Secrets, especially core credentials, are found in the frontend suggests that basic security principles are being seriously overlooked within some development teams/organizations. This may be evidence of organizational lack of awareness or inadequate management, going beyond individual mistakes. The fact that mistakes occur despite service providers like AWS, Stripe clearly warning against including sensitive keys in client-side code in official documentation suggests the possible existence of structural problems such as a speed-first culture, lack of education and awareness, poor review processes, absence of automated safeguards, the paradox of developer experience (DX), etc.

Ultimately, frontend Secret exposure is likely the result of a combination of multiple factors acting together, beyond individual carelessness, such as the organization's security culture, development processes, education, technical safeguards, etc., and may show that the principle 'security is everyone's responsibility' is not being properly realized.

5. The Destructive Power of Leaked Secrets: Impact on Real Business

Leaked Stripe Secret (sk_live)

Leaked Stripe Secret/Restricted Keys can inflict immediate and severe damage. Attackers can use the stolen key to call the Stripe API to perform various malicious activities such as direct monetary theft (creating fraudulent payments, imposing recurring charges, processing unauthorized refunds, attempting to change bank account information, etc.), sensitive data leakage (mass leakage of customer PII leading to legal liability and loss of trust), and service manipulation and interruption (arbitrary manipulation of product information, interference with website operation, Stripe account suspension).

The Broad Threat of Leaked AWS Secret Access Keys

The scope and severity of damage from a leaked AWS Secret Access Key depend on the IAM user/role permissions associated with that key. If the principle of least privilege is observed, the damage can be limited, but with administrator-level permissions, almost any kind of damage is possible.

After key theft, attackers perform reconnaissance activities to identify permissions using sts:GetCallerIdentity, etc., and then, based on the identified permissions, can attempt various malicious activities such as causing significant financial loss (cryptocurrency mining through mass execution of high-performance EC2 instances), leaking, altering, or destroying core data (S3, RDS, DynamoDB data leak/modification/deletion), additional penetration and privilege escalation (expanding access rights and securing persistent access paths through Lateral Movement & Privilege Escalation), and changing infrastructure settings (changing security group rules, changing VPC configurations, modifying Lambda code, etc.).

Attackers automatically detect and exploit exposed AWS keys very quickly (sometimes within minutes). Although AWS has warning systems, damage can occur before that.

Cloud Environment: Amplification of Damage Scope

Leakage of cloud service API keys like AWS, Stripe is more than paralysis of a single function. Cloud environments have numerous services (compute, storage, DB, etc.) and data closely interconnected, so upon theft of one high-level permission credential (Secret Key), almost all assets under that account are simultaneously at risk. This means the "blast radius" is much larger than in traditional on-premises environments.

With one leaked AWS key, access/manipulation of multiple services like EC2, S3, RDS, Lambda, VPC, IAM is possible, and a Stripe Secret Key can be used to access a wide range of financial/business functions such as payments, customer information, products, subscriptions, settlements, etc. After initial access, attackers gradually expand their access scope through Reconnaissance, Lateral Movement, and Privilege Escalation, aiming for complete environment takeover or maximum damage. Therefore, cloud environment Secret key leakage must be recognized as a potential risk that can cause serious disruption to business operations, and approached from a 'systemic defense' perspective that considers the interconnectivity of the entire system, going beyond the protection of individual credentials.

6. Why Does Sensitive Information Leak to the Frontend?

Frontend Secret exposure incidents are likely the result of a combination of various technical, procedural, and cultural factors acting together rather than a single cause. Major causes include failure of environment variable management, indifference towards complex build processes, Git commit mistakes, lack of security awareness, and pitfalls of the framework itself.

Environment variable management failure is one of the most common direct causes. Misusing Next.js's NEXT_PUBLIC_ prefix rule by mistakenly attaching this prefix to a server-only Secret causes the actual value to be included in the client bundle.

Furthermore, configuration errors in next.config.js of older Next.js versions, poor management like committing .env files containing Secrets to Git due to .gitignore omission, and inappropriate Secret management methods for environment variables themselves (plaintext storage, exposure possibility, difficulty in systematic management) also become causes.

Complex build processes and indifference towards them also cause problems. In the process where build tools replace environment variable references with actual values (Inlining), server-only Secrets can be hardcoded into the client bundle, and if the Code Elimination feature does not work perfectly, server-only code might remain in the client bundle and leak.

Git commit mistakes are a clear cause where files containing Secrets are directly committed to Git repositories (especially public repositories). Errors or omissions in .gitignore settings are the main reason, but private repositories are also risky if access permission management is poor. Attackers use automated tools to scan platforms like GitHub to quickly find and exploit leaked Secrets.

Besides technical mistakes, a fundamental lack of security awareness among developers or relevant personnel often causes Secret leakage. There is a tendency to overlook the inherent public nature of frontend code, lack understanding of safe Secret management methods for the framework/platform being used, or prioritize convenience over security with a complacent attitude like "It's just the frontend anyway...".

Advanced features provided by modern full-stack frameworks like Next.js make the boundary between client and server code flexible, but if the developer does not clearly understand the execution context (client, server, build time), it can cause confusion and lead to security mistakes. Cases include mistakenly writing Secret handling logic that should only run on the server into a client component, or using incorrect data fetching strategies. The abstraction features of the framework can actually cause basic security principles to be overlooked, so an accurate understanding of the operating mechanism and execution context is essential.

Specifically, the NEXT_PUBLIC_ prefix rule was originally designed for controlled information exposure, but if a developer incorrectly judges that a sensitive Secret must be used directly on the client and attaches this prefix, the Secret's value is exposed as is, creating a paradoxical situation where it becomes the main culprit of a leakage incident. A feature created for convenience creates serious security vulnerabilities when misused.

7. Defense Strategy: A Multi-Layered Approach for Preventing Secret Exposure

To prevent the serious security threat of frontend Secret exposure and build secure web applications, rather than relying on a single solution, a multi-layered defense strategy must be established and executed, ranging from architecture design to code writing, build/deployment pipelines, operating environment settings, and continuous monitoring.

The most basic and absolute rule to follow is to keep Secrets only on the server. Sensitive credentials such as AWS Secret Access Keys, Stripe Secret/Restricted Keys, DB passwords, etc., must absolutely not be included in frontend code or exposed in a form directly accessible by the client. All sensitive information processing and external service authentication must be performed in a trusted server-side environment (backend API, serverless functions, etc.).

Secure environment variable management is also important. Clearly distinguish between server-only variables and client-exposable variables, and use prefixes like Next.js's NEXT_PUBLIC_ very restrictively only for non-sensitive configuration values like Google Analytics ID. When using the Vercel platform, managing environment variables via the dashboard/CLI is recommended, utilizing the separation setting feature for production/preview/development environments, and it is good practice to activate the "Sensitive" option for important Secrets. Also, .env files potentially containing Secrets must be added to .gitignore to prevent commits.

At the architectural level, introducing the Backend-for-Frontend (BFF) or API Proxy pattern can be a fundamental solution.

In this pattern, the frontend communicates with a dedicated backend server (BFF) instead of directly calling external APIs. All sensitive Secrets are securely stored inside the BFF, and external service calls are performed by the BFF instead. Through this, Secrets can be completely isolated from the frontend, API responses optimized, and development efficiency increased by separating concerns.

Regarding the method of injecting environment variables, one must recognize the risks of build-time injection and consider runtime processing if necessary. Injection via NEXT_PUBLIC_, etc., determines the value at build time and hardcodes it into the code, making changes after build impossible. If using the same build artifact in staging/production environments while needing to apply different settings per environment, consider runtime processing methods such as using server-side runtime environment variables, dynamic configuration loading, implementing a custom server or initialization loader, etc. The most suitable method must be carefully chosen considering requirements, deployment strategy, and sensitivity.

For a higher level of security and management efficiency, actively consider adopting professional Secret management solutions. Various solutions like HashiCorp Vault, AWS Secrets Manager, Google Cloud Secret Manager, Azure Key Vault, Doppler, Infisical provide powerful features such as centralized management of Secrets, strong access control (RBAC), automatic rotation, detailed audit logs, encryption at rest, support for solving the "Secret Zero" problem, platform/tool integration, etc., helping to compensate for the limitations of the environment variable method and strengthen the security posture.

Finally, to compensate for human error, introduce automated Secret scanning and pay attention to configuration management. Integrating scanning tools like Gitleaks, detect-secrets, TruffleHog into the CI/CD pipeline to fail the process upon Secret detection before the build/deploy stage, and setting up Pre-commit Hooks in the developer's local environment to prevent commits/pushes at the source is effective.

At this time, it is important to choose an accuracy-focused tool with a low false positive rate (e.g., Cremit with validation features). Also, activating built-in scanning features of GitHub/GitLab, etc., and utilizing professional monitoring services like GitGuardian to continuously monitor repositories is a good method. Accurately understanding and carefully configuring platform setting options like Vercel is also essential.

In conclusion, effective Secret management can only be achieved when a multi-layered approach, comprehensively applying secure architecture design, careful environment variable and configuration management, utilization of professional solutions and attention to platform settings, integration of automated verification, continuous developer education, etc., is applied.

8. Conclusion: The Urgency of Non-Human Identity (NHI) Security Management

Frontend Secret Leakage: A Realistic Threat, Not Theory

This study, through the discovery of validated Secret leakage in approximately 0.37% of services hosted on Vercel, has quantitatively shown that frontend Secret exposure is no longer a theoretical possibility or a rare case. In particular, behind the convenience of modern development tools/platforms like SPAs, Vercel, Next.js, it was confirmed that new risk factors are inherent, such as complexity in environment variable management, build process pitfalls, ambiguity of client/server boundaries, etc., where developers can unintentionally commit serious security mistakes.

Exposed Secrets are Not Simple Strings but Non-Human Identities (NHIs)

The AWS Secret Access Keys, Stripe API Keys, GitHub PATs, etc., discovered in the study are not simple data fragments, but Non-Human Identities (NHIs), i.e., machine identities, that 'machines'/'software' such as systems, applications, scripts use to authenticate themselves and receive authorization when interacting with other systems. Like human user accounts, specific roles and permissions are assigned to NHIs as well.

Therefore, NHI (Secret) leakage means more than information exposure; it signifies that all permissions and capabilities granted to that identity can be hijacked by attackers. This is a very serious security threat that can directly lead to unauthorized access, manipulation, or destruction of corporate core cloud infrastructure, financial systems, source code, sensitive data, etc. The theft of just one powerful NHI can paralyze entire corporate operations or cause significant losses.

NHI Security: An Indispensable Element of Modern Development Environments

The phenomenon of NHIs (Secrets) being exposed in inappropriate locations like frontend code is a prime example showing that NHI management is not being properly conducted throughout the development process and deployment pipeline. Many organizations, focusing on development speed and convenience of feature implementation, tend to neglect the overall lifecycle management of the numerous NHIs connecting applications and infrastructure, from creation to storage, least privilege assignment, validity period management/rotation, and revocation.

To build secure software supply chains and robust cloud-native environments, in addition to securing the code itself, establishing a thorough and systematic security management framework for the numerous NHIs that execute it and connect services is essential. From initial development through deployment, operation, and revocation, all NHIs must be identified, classified, protected, and their usage status and activity history continuously monitored and audited. With cloud environments and the spread of automation, the number of NHIs is increasing exponentially, and managing them as thoroughly as, or even more thoroughly than, human user accounts is a key task of the modern security paradigm.

Solutions like Cremit accurately detect NHIs (Secrets) scattered throughout environments such as code repositories and configuration files, minimize false positives through validity/permission verification, and provide centralized visibility and management functions, thereby effectively managing the risk of unintentional NHI exposure and contributing to maintaining secure development/operation environments.

Ultimately, the overall security level of modern applications and cloud infrastructure largely depends on how effectively Non-Human Identities are identified, managed, and protected. We hope the results of this study will serve as an opportunity for the development community and businesses to newly recognize the importance of NHI security, and prompt the establishment of safer development cultures and processes, and the review of adopting related solutions.