DEV Community: Louis Wright

Your .env Is Not Where Your Secrets End Up: Scanning the Bundle You Actually Ship

Louis Wright — Wed, 14 Oct 2026 09:52:07 +0000

This article was written with AI assistance and reviewed by the author.

In 2019, researchers at North Carolina State University went looking for API keys and private keys in public GitHub repositories. Their NDSS paper, "How Bad Can It Git?", found that secret leakage was pervasive, affecting over 100,000 repositories, and that thousands of new, unique secrets were leaked every day [1].

Most of the advice that followed focused on the repository: add .env to .gitignore, run a pre-commit scanner, never commit credentials. That advice is good. But there is a second place secrets leak that a clean repository does not protect you from: the JavaScript bundle you ship to every visitor.

How a secret walks out of the build

Modern frontend tools deliberately copy some environment variables into client code. Vite's documentation says it plainly: variables prefixed with VITE_ are exposed in client-side source code after bundling, and it warns you to avoid that prefix to prevent leaking variables to the client [2]. Next.js works the same way: to expose a variable to the browser it must be prefixed with NEXT_PUBLIC_, and those values are inlined into the JavaScript bundle during next build [3].

So the failure mode is not exotic. Someone needs a key "just for a quick test", gives it the public prefix (or pastes it straight into a config object), and the build faithfully writes the literal value into dist/assets/index-<hash>.js. The .env file never touches git. The secret still ends up on the public internet.

MITRE classifies this family of mistakes as CWE-798, Use of Hard-coded Credentials [4]. Once a key has shipped, deleting it from the next build is not enough. OWASP's Secrets Management Cheat Sheet notes that restarting an application does not revoke stolen credentials; they remain usable until the backing service expires or revokes them [5]. The only real fix is rotation.

Checking the artifact, not just the source

Source scanners look at what you wrote. The browser sees what the bundler produced. bundle-secret-guard is a small CLI that scans built frontend output (it auto-detects dist, build, out, .next/static, .output/public and .svelte-kit/output/client) and fails when secrets or API keys made it into the files you are about to deploy. It can also cross-check the values in your .env files, so a server-only value that appears literally in the bundle is flagged even if it does not match a known key format.

A demo build (with fake keys)

To be upfront: the project below is made up for this article, and every key in it is fake. The AWS pair is a widely used example key pair (note the EXAMPLE suffix), and the Stripe value is a placeholder shaped like a live key. The .env:

VITE_API_URL=https://api.example.com
STRIPE_SECRET_KEY=sk_live_51Hx9QkFakeDemoKey0000000000000000000000000000

And a "built" bundle at dist/assets/index-3f9a1c.js where someone hard-coded the config:

const cfg={apiUrl:"https://api.example.com",stripe:"sk_live_51Hx9QkFakeDemoKey0000000000000000000000000000",aws:{accessKeyId:"AKIAIOSFODNN7EXAMPLE",secretAccessKey:"wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"}};

Running npx bundle-secret-guard dist -e .env with version 1.1.1 gives this real output:

Four errors, each with a file, line and column, and the secret itself masked in the output:

a Stripe live secret key, matched by format;
the same value flagged again as a server-only env leak, because it matches STRIPE_SECRET_KEY from .env;
an AWS access key ID;
an AWS secret access key.

Every fix starts the same way: rotate the key, because anything that was deployed must be treated as leaked. Then it points to where the call belongs instead, such as a server or API route, a serverless function, or pre-signed URLs for AWS. The command exits with code 1, so a CI job stops before the deploy step.

Wiring it into CI

Run it after the build and before the deploy:

- run: npm run build
- name: Check bundle for secrets
  run: npx bundle-secret-guard@1 dist -e .env.production --sarif bundle-secrets.sarif

Useful options:

--baseline <file> and --update-baseline to accept known findings (stored as hashes only) and fail only on new ones.
--entropy-scan for extra high-entropy string detection.
--gitleaks <file> to reuse existing gitleaks TOML rules.
--verify is opt-in and checks whether a key is live using the provider's own API. It is off by default.

The takeaway

The 2019 study showed how often secrets slip into source code [1]. Build tools add a second path, because public env prefixes are designed to be copied into client code [2][3]. Scan the artifact you actually deploy, and if a key ever ships, rotate it rather than just removing it [5].

References

Meli, M., McNiece, M. R. and Reaves, B. (North Carolina State University). "How Bad Can It Git? Characterizing Secret Leakage in Public GitHub Repositories". NDSS Symposium, 2019. https://www.ndss-symposium.org/ndss-paper/how-bad-can-it-git-characterizing-secret-leakage-in-public-github-repositories/
Vite. "Env Variables and Modes". Accessed Oct 2026. https://vite.dev/guide/env-and-mode
Vercel. "Next.js Docs: Environment Variables". Accessed Oct 2026. https://nextjs.org/docs/app/guides/environment-variables
MITRE. "CWE-798: Use of Hard-coded Credentials". Accessed Oct 2026. https://cwe.mitre.org/data/definitions/798.html
OWASP. "Secrets Management Cheat Sheet". Accessed Oct 2026. https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html

A Version Tag Leaked CI Secrets: Lessons From CVE-2025-30066 for Your GitHub Actions

Louis Wright — Wed, 14 Oct 2026 09:45:49 +0000

This article was written with AI assistance and reviewed by the author.

On March 14 and 15, 2025, the version tags of a popular GitHub Action stopped meaning what everyone thought they meant. A threat actor modified the tags v1 through v45.0.7 of tj-actions/changed-files so they pointed at a single malicious commit, 0e58ed8. The result, as recorded in the National Vulnerability Database, was that remote attackers could discover secrets by reading Actions logs [1]. NVD rates it 8.6 (High) and tracks it as CVE-2025-30066 [1].

Nobody had to change a line of their own workflow to be affected. If a pipeline said uses: tj-actions/changed-files@v45, the next run quietly fetched the attacker's code.

Why a tag is not a version

A git tag feels like a release number, but it is just a movable pointer. Whoever controls the upstream repository can move it. That is exactly what happened here [1].

CISA's alert on the incident asked organizations to audit every project that used any version of tj-actions/changed-files between 2025-03-12 and 2025-03-15, and for public repositories that ran the malicious commit, to check for exposed access keys, GitHub Personal Access Tokens, npm tokens and private RSA keys [2]. In other words: assume anything the workflow could see was compromised.

GitHub's own guidance has long pointed at the fix. Its secure-use reference recommends pinning actions to a full-length commit SHA, because an attacker would then need a SHA-1 collision for a valid Git object to slip in a backdoor [3]. The same page notes that workflow dependency lockfiles now supersede SHA pinning for repositories that adopt them [3], so check which option fits your setup.

The quieter cousins of the same mistake

A retagged action is the dramatic case. GitHub Actions has a few other well-documented ways for an outsider to end up running code with your secrets:

Pwn requests. GitHub Security Lab warns that combining the pull_request_target trigger with an explicit checkout of an untrusted pull request is a dangerous practice that may lead to repository compromise [4].
Script injection. Fields such as github.event.pull_request.title are attacker controlled. The recommended fix is to pass them through an intermediate environment variable instead of interpolating ${{ }} straight into a run: script [5].
Over-privileged tokens. GitHub advises granting the GITHUB_TOKEN the minimum required permissions, with read-only access to repository contents as a good default [3].

Each of these is easy to spot in code review once you know the pattern, and easy to miss in a 200-line YAML file at 6pm on a Friday.

Letting a tool do the staring

workflow-sentinel is a small CLI that scans .github/workflows/*.yml and action.yml files and fails the build when it finds these patterns. To see it work, here is a deliberately bad workflow that combines all of the problems above:

name: PR checks
on: pull_request_target
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha }}
      - uses: tj-actions/changed-files@v45
        id: changed
      - run: echo "Checking ${{ github.event.pull_request.title }}"
      - run: npm ci && npm test
        env:
          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

Running npx workflow-sentinel (version 1.1.0) in that repository produces this real output:

Seven findings, each tied to a line number and a concrete fix: two CRITICAL (the pull-request-head checkout under pull_request_target, and the title interpolated into run:), three HIGH (two mutable tags, plus secrets exposed to a job running PR code) and two MEDIUM (no permissions: block, and checkout without persist-credentials: false). The exit code is non-zero because the default --fail-on level is high.

For contrast, the same command against the current workflows in the expressjs/express repository reported 0 findings across 5 files and passed.

Fixing it, not just flagging it

The part that makes this practical on a real codebase is --fix. It pins actions to commit SHAs using the GitHub API (with GH_TOKEN or GITHUB_TOKEN), and --fix-dry-run shows the changes first. A few other options:

--trusted-owner actions skips SHA-pin requirements for owners you choose to trust.
--sarif <file> emits SARIF 2.1.0 for GitHub code scanning.
--json and --markdown for reports and PR comments.

A minimal CI step:

- name: Harden workflows
  run: npx workflow-sentinel@1 --sarif workflow-sentinel.sarif

The takeaway

CVE-2025-30066 did not exploit a bug in anyone's application. It exploited a habit: trusting that @v45 means the same code tomorrow as it did yesterday [1]. Pin what you run, give the token as little as possible, and keep attacker-controlled strings out of shell scripts [3][4][5]. Then let a linter check it on every push, because the YAML will keep changing.

References

NIST National Vulnerability Database. "CVE-2025-30066 Detail". 2025. https://nvd.nist.gov/vuln/detail/CVE-2025-30066
CISA. "Supply Chain Compromise of Third-Party tj-actions/changed-files (CVE-2025-30066) and reviewdog/action-setup@v1 (CVE-2025-30154)". 2025. https://www.cisa.gov/news-events/alerts/2025/03/18/supply-chain-compromise-third-party-tj-actionschanged-files-cve-2025-30066-and-reviewdogaction
GitHub Docs. "Secure use reference". Accessed Oct 2026. https://docs.github.com/en/actions/reference/security/secure-use
GitHub Security Lab (jarlob). "Keeping your GitHub Actions and workflows secure Part 1: Preventing pwn requests". 2021. https://securitylab.github.com/resources/github-actions-preventing-pwn-requests/
GitHub Security Lab (jarlob). "Keeping your GitHub Actions and workflows secure Part 2: Untrusted input". 2021. https://securitylab.github.com/resources/github-actions-untrusted-input/

81% of Sites Ship Without a CSP Header. Here Is How to Catch Yours in CI

Louis Wright — Wed, 14 Oct 2026 09:27:13 +0000

This article was written with AI assistance and reviewed by the author.

Here is a number that should bother anyone who ships websites: in the HTTP Archive's 2024 crawl, only 19% of hosts sent a Content-Security-Policy header [1]. Flip that around and roughly four out of five sites go live with no CSP at all. HSTS fares little better: just 30% of mobile responses carried a Strict-Transport-Security header [1].

These are not exotic, cutting-edge defenses. They are one-line response headers. So why are they missing so often?

The header that quietly disappears

My theory, after watching it happen on my own projects: headers are rarely forgotten. They are lost. Someone sets them up in Nginx, then the site moves to a CDN. A framework upgrade changes the default middleware. A new preview environment gets its own config. Nobody notices, because a missing header breaks nothing. The page still loads, the tests still pass, and the only person who finds out is the one probing for weaknesses.

The data backs up how uneven this is. Among the top 1,000 sites on mobile, 64.3% enable HSTS, but adoption drops steadily as you move down the popularity ranks [1]. And even where a CSP exists, it often does less than it seems: 91% of desktop sites with a CSP allow 'unsafe-inline' in script-src [1], which undermines the XSS protection CSP is meant to provide [1][3].

What each header actually buys you

A quick tour, so the scanner output below makes sense:

Strict-Transport-Security tells the browser to only reach your site over HTTPS. It was standardized in RFC 6797 to defend against man-in-the-middle attacks that downgrade connections to plain HTTP [2][4].
Content-Security-Policy lets you restrict which sources may load scripts and other resources, reducing the impact of cross-site scripting [3][5].
X-Frame-Options or CSP frame-ancestors stops other sites from framing your pages, the core defense against clickjacking [6].
X-Content-Type-Options: nosniff tells the browser not to MIME-sniff responses, so the declared content type is respected [7].

OWASP's Secure Headers Project maintains a broader catalogue of recommended headers and values if you want to go deeper [8].

Turning it into a test

The fix for "lost" headers is the same as for any regression: test for it continuously. That is why I built header-sentinel, a small CLI that fetches your deployed URLs and fails when security headers are missing or misconfigured. Grades follow the Mozilla HTTP Observatory scoring model, where every site starts at a baseline of 100 and modifiers are applied per test [9].

Install-free:

npx header-sentinel https://example.com https://github.com --fail-on none

Here is real output from version 1.1.1 against two sites today:

https://example.com/ (HTTP 200)  Grade D score 30/100 - MEDIUM risk
  x error Strict-Transport-Security missing [hsts]
  x error Content-Security-Policy missing [csp]
  x error Clickjacking protection missing [frame-options]
  x error X-Content-Type-Options missing [content-type-options]
  ! warn  Referrer-Policy missing [referrer-policy]
  ! warn  Permissions-Policy missing [permissions-policy]
  ! warn  Cross-Origin-Opener-Policy missing [coop]

https://github.com/ (HTTP 200)  Grade A+ score 115/100 - LOW risk
  ! warn  CSP style-src allows 'unsafe-inline' [csp-unsafe-inline]
  ! warn  Permissions-Policy missing [permissions-policy]
  ! warn  Cross-Origin-Opener-Policy missing [coop]
  ! warn  Set-Cookie present (3 headers) [cookies]

2 URL(s) scanned: 4 error(s), 7 warning(s)

Two things I like about this output. First, every finding comes with a copy-paste fix for Nginx, Express (helmet) and Vercel/Netlify, so the error message is also the patch. Second, even an A+ site gets useful nudges: GitHub's CSP allows 'unsafe-inline' for styles, and the tool says so.

Wiring it into CI

The default --fail-on error exits non-zero on any error, which is exactly what you want after a deploy step:

- name: Check security headers
  run: npx header-sentinel@1 https://staging.example.com --sarif headers.sarif

Other options worth knowing:

--sitemap <url> scans every URL in your sitemap.
--baseline <file> reports only new findings, so you can adopt it on a legacy site without a wall of red.
--sarif writes SARIF 2.1.0 for GitHub code scanning.
--json for your own dashboards.

The takeaway

Security headers are cheap to add and easy to lose. The Web Almanac numbers say most of the web is still missing them [1]. Treat them like any other contract your deployment must honor, and let a test tell you the day one goes missing.

References

Franken, G. and Vanderlinden, V. (HTTP Archive). "Security", Web Almanac 2024. 2024. https://almanac.httparchive.org/en/2024/security
Hodges, J., Jackson, C. and Barth, A. (IETF). "RFC 6797: HTTP Strict Transport Security (HSTS)". 2012. https://www.rfc-editor.org/rfc/rfc6797
MDN Web Docs (Mozilla). "Content Security Policy (CSP)". Accessed Oct 2026. https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP
MDN Web Docs (Mozilla). "Strict-Transport-Security". Accessed Oct 2026. https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Strict-Transport-Security
W3C. "Content Security Policy Level 3". Accessed Oct 2026. https://www.w3.org/TR/CSP3/
OWASP. "Clickjacking Defense Cheat Sheet". Accessed Oct 2026. https://cheatsheetseries.owasp.org/cheatsheets/Clickjacking_Defense_Cheat_Sheet.html
MDN Web Docs (Mozilla). "X-Content-Type-Options". Accessed Oct 2026. https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-Content-Type-Options
OWASP. "OWASP Secure Headers Project". Accessed Oct 2026. https://owasp.org/www-project-secure-headers/
MDN Web Docs (Mozilla). "HTTP Observatory: Tests and scoring". Accessed Oct 2026. https://developer.mozilla.org/en-US/observatory/docs/tests_and_scoring