DEV Community: Louis Wright

Sephora Paid $1.2M for Ignoring Global Privacy Control. Check Your Site in CI

Louis Wright — Tue, 20 Oct 2026 04:06:38 +0000

This article was written with AI assistance and reviewed before publishing. The demo site used in the examples is made up for this article.

On August 24, 2022, California's Attorney General announced a $1.2 million settlement with Sephora. The allegations were simple: Sephora sold customers' personal information without telling them, and it failed to process opt-out requests sent through user-enabled global privacy controls such as the Global Privacy Control (GPC) [1]. On the same day, the office said it had sent notices to a number of other businesses over the same failure to process GPC opt-outs [1].

Nobody at Sephora had to click a button for that to happen. A shopper's browser sent a signal, the site did not act on it, and advertising tags kept loading. Almost three years later, in July 2025, the same office announced a $1.55 million settlement with Healthline.com, describing it at the time as the largest CCPA settlement to date. One of the allegations was that Healthline kept sharing data with some advertising third parties even for consumers who had opted out, and the announcement spelled out that businesses must honour opt-out requests, including those sent through GPC [2].

If you ship a site with a Meta Pixel, a TikTok Pixel or a LinkedIn Insight Tag on it, this is a frontend problem as much as a legal one. This post walks through what the signal actually is, what "honouring" it means in code, and how to catch the gaps in CI with an open-source CLI called gpc-warden.

What GPC actually sends

Global Privacy Control is a W3C specification. When a user turns it on, the browser does two things [3]:

It adds a Sec-GPC: 1 request header to the requests it makes.
It exposes navigator.globalPrivacyControl, a read-only boolean that tells your scripts whether that header was sent for the current top-level page.

The spec also defines an optional support resource at /.well-known/gpc.json. Its gpc member must be true (the server intends to abide by GPC requests, at least as far as it is legally obliged to) or false, and an optional lastUpdate member holds a YYYY-MM-DD date [3]. A valid file looks like this:

{ "gpc": true, "lastUpdate": "2026-10-20" }

California's own CCPA guidance lists the right to opt out of the sale or sharing of personal information "including via the GPC", and tells consumers they can submit an opt-out request through a user-enabled global privacy control [4]. So the header is not a hint. Under that guidance it is a request your site is expected to act on.

Why sites get this wrong

Reading a boolean is easy. The hard part is that most ad tags are pasted straight into a layout as a bare <script async src="...">. A tag loaded like that runs on every page view, and there is no point at which your code gets to ask "did this visitor opt out?" before the pixel fires.

Honouring GPC in a static or mostly static site comes down to two things:

Some code has to read the signal: an inline script, a loader in your own JS bundle, an edge or serverless function that looks at Sec-GPC, or a consent management platform (CMP) configured to respect it.
Every sale/share tag has to load in a way that code can stop: through that loader, or tagged so your CMP controls it (for example type="text/plain" plus a category attribute).

Miss either one and the signal is effectively ignored, even if your privacy policy says otherwise.

Checking a built site with gpc-warden

gpc-warden is a zero-dependency Node.js CLI, library and GitHub Action that inspects the folder your build writes (Astro, Next.js output: 'export', Eleventy, Hugo, Jekyll, Docusaurus, VitePress or plain HTML). It runs offline and checks:

whether any inline script, local JS file or edge/serverless function in the build reads navigator.globalPrivacyControl or Sec-GPC;
whether advertising vendors that sell or share data (Meta, Google Ads, TikTok, LinkedIn, X, Pinterest, Snap, Microsoft, Criteo, Taboola and others) load unconditionally;
whether /.well-known/gpc.json exists, is valid, and does not say false while sale/share tags are present;
whether the privacy policy mentions GPC or opt-out preference signals.

It needs Node.js 18 or newer:

npx gpc-warden dist
npx gpc-warden dist --fail-on medium
npx gpc-warden out --format sarif > gpc.sarif

Here is a run against a small demo shop (made up for this article). The home page pastes in the Meta and TikTok pixels directly, there is no gpc.json, and the privacy page only talks about a "Do Not Sell" link:

<!-- demo/before/index.html (made-up demo) -->
<script async src="https://connect.facebook.net/en_US/fbevents.js"></script>
<script async src="https://analytics.tiktok.com/i18n/pixel/events.js"></script>

Three high findings fail the run with exit code 1: no code reads the signal, and each pixel loads unconditionally. The two low findings point at the missing gpc.json and the policy wording. Every finding comes with a concrete fix.

Fixing the demo

The fix is a small loader that only injects the sale/share tags when the browser has not sent a GPC opt-out:

// demo/after/js/ads.js (made-up demo)
// Load sale/share tags only when the browser has not sent a GPC opt-out.
if (navigator.globalPrivacyControl !== true) {
  for (const src of [
    'https://connect.facebook.net/en_US/fbevents.js',
    'https://analytics.tiktok.com/i18n/pixel/events.js',
  ]) {
    const s = document.createElement('script');
    s.async = true;
    s.src = src;
    document.head.appendChild(s);
  }
}

The page now includes <script src="/js/ads.js"></script> instead of the two pixels, the build publishes /.well-known/gpc.json, and the privacy policy says a GPC signal is treated as a request to opt out of sale and sharing. In a real site you would also combine this with your consent logic and read Sec-GPC server-side where you set cookies or forward data. Re-running the check:

gpc-warden — https://shop.example
2 page(s); 0 sale/share vendor(s); GPC handling found in js/ads.js

no findings
✔ Passing (fail-on: high).

If you use a CMP such as OneTrust, Osano, Usercentrics, Didomi, Termly, Ketch, TrustArc or Transcend, gpc-warden spots it, but it cannot see your dashboard settings. Once GPC support is switched on in the CMP, pass --cmp-honours-gpc (or set "cmpHonoursGpc": true in config) to confirm it.

Running it in CI

The repository ships a GitHub Action that runs the bundled CLI with no install step. Build the site first, then point the action at the output folder:

permissions:
  contents: read
  security-events: write   # only needed for the SARIF upload
jobs:
  gpc-warden:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@11d5960a326750d5838078e36cf38b85af677262 # v4
        with: { persist-credentials: false }
      - run: npm ci && npm run build
      - uses: MrLouisWright/gpc-warden@v1
        with:
          path: dist
          fail-on: high
          sarif: gpc-warden.sarif
      - uses: github/codeql-action/upload-sarif@v3
        if: always()
        with: { sarif_file: gpc-warden.sarif }

By default it also adds a Markdown report to the job summary. Exit codes are 0 for a pass, 1 for findings at or above --fail-on, and 2 for usage or config errors, so it works the same way in any other CI system with a plain npx gpc-warden dist step.

For pages that genuinely do not need the check, the config file supports a time-boxed allowlist. Each entry needs a reason, and once its expires date passes the finding comes back along with an allowlist-expired finding:

{
  "failOn": "medium",
  "allowlist": [
    {
      "rule": "gpc-tracker-not-suppressed",
      "subject": "/landing/*",
      "reason": "Landing pages served only outside the US",
      "expires": "2027-03-31"
    }
  ]
}

There is also a small library API if you want to wire the checks into your own tooling:

import { check, validateGpcJson } from "gpc-warden";
const report = check("dist");
validateGpcJson(JSON.stringify({ gpc: true, lastUpdate: "2026-10-01" })); // null

What it does not do

gpc-warden is a static check of your build output. It cannot prove that a tag is actually suppressed at runtime, it does not audit consent banners (a sibling tool, consent-warden, covers those) or build a full tracker inventory (tracker-warden does that), and it is not legal advice. What it does is catch the most common, most mechanical mistake: an ad tag sitting in the HTML where no GPC check can ever reach it.

The takeaway

Regulators in California have already treated an ignored GPC signal as an ignored opt-out, first with Sephora [1] and again with Healthline [2]. The spec gives you a clear header, a clear JavaScript property and a clear declaration file [3]. Gate your sale/share tags behind the signal, publish gpc.json, say so in your policy, and let CI fail the build when a pixel slips back in.

Project site: https://mrlouiswright.github.io/gpc-warden/
npm: https://www.npmjs.com/package/gpc-warden
GitHub: https://github.com/MrLouisWright/gpc-warden

Louis Wright

References

State of California Department of Justice, Office of the Attorney General. "Attorney General Bonta Announces Settlement with Sephora as Part of Ongoing Enforcement of California Consumer Privacy Act". 2022. https://oag.ca.gov/news/press-releases/attorney-general-bonta-announces-settlement-sephora-part-ongoing-enforcement
State of California Department of Justice, Office of the Attorney General. "Attorney General Bonta Announces Largest CCPA Settlement to Date, Secures $1.55 Million from Healthline.com". 2025. https://oag.ca.gov/news/press-releases/attorney-general-bonta-announces-largest-ccpa-settlement-date-secures-155
W3C (Zimmeck, S., Snyder, P., Brookman, J., Zucker-Scharff, A., eds.). "Global Privacy Control (GPC)". W3C Working Draft, 2026. https://www.w3.org/TR/gpc/
State of California Department of Justice, Office of the Attorney General. "California Consumer Privacy Act (CCPA)". Accessed Oct 2026. https://oag.ca.gov/privacy/ccpa

23% of News Pages Have a Broken Link. Catch Yours Before Deploy

Louis Wright — Fri, 16 Oct 2026 04:07:09 +0000

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

In May 2024, Pew Research Center reported that 23% of news webpages in its sample contained at least one broken link, and 21% of government webpages did too [1]. Across a decade of Common Crawl snapshots, a quarter of pages that existed between 2013 and 2023 were already inaccessible by October 2023 [1]. Link rot is not a niche SEO footnote. It is a measurable property of the public web.

Yet many static sites still discover 404s the hard way: after deploy, after a CDN purge, after a user files a ticket. Source review and local preview often miss the problems that only appear in the built output on a case-sensitive host.

That is the gap static-link-sentinel is built for. It crawls dist/, build/, out/, public/, or _site/ before you ship, maps URLs the way Netlify, Vercel, GitHub Pages, and Cloudflare Pages do, and fails CI when links, assets, anchors, or sitemap entries do not resolve.

The build is not the source tree

A Markdown link that looks fine in the editor can still point at a page the bundler never emitted. An image path that works on a default macOS volume can 404 on Linux. Amazon S3 documents that object key names are case sensitive: Logo.png and logo.png are different objects [2]. Local APFS defaults often hide that mismatch. Production hosts and object stores do not.

Google's crawl guidance is equally blunt about the cost of pretending missing pages still exist. Soft 404s (error-like or empty pages that still return HTTP 200) keep getting crawled and waste crawl budget; Google recommends returning a real 404 or 410 for permanently removed content and avoiding long redirect chains [3][4]. Broken internal links and stale sitemap entries feed exactly that mess.

So the useful check is not "does this string look like a URL in the repo?" It is "given the files that will actually be served, does every reference resolve the way the host will resolve it?"

What static-link-sentinel actually checks

static-link-sentinel is a zero-dependency CLI and library for Node 18+. Point it at a built directory (or let it auto-detect common output folders). It walks HTML, CSS, web manifests, sitemap*.xml, and robots.txt, plus optional Markdown/MDX sources.

Internal findings include:

broken-link and missing-asset: pages, scripts, stylesheets, images, and related refs with no matching file
case-mismatch: a path that only matches when letter case is ignored (works on many Mac volumes, fails on Linux/CDN origins)
missing-fragment: #anchors with no matching id or name
sitemap-url / robots-sitemap: sitemap or robots entries that are not in the build
mixed-content and related HTTPS warnings when a site URL is known
optional orphan-page reporting with --orphans

With --external, unique outbound URLs are checked (HEAD with GET fallback), including redirect chains hop by hop, with caching for CI reruns.

URL resolution understands clean URLs, index.html, trailing-slash policy, basePath, Netlify _redirects, and vercel.json redirects/rewrites/cleanUrls. Exit codes are 0 (pass), 1 (findings at or above --fail-on), and 2 (usage error). Output can be pretty CLI, JSON, SARIF 2.1.0, or Markdown. Vite and webpack plugins and a GitHub Action are included.

None of that invents a live server. The tool maps paths to files the same way those hosts do.

A labelled demo on a tiny dist

The following is example/demo data, not a production site: a three-page build with intentional typos, a case-mismatched image path, a missing CSS background, a bad fragment, and a sitemap URL for a page that was never built.

npx static-link-sentinel dist --site-url https://demo.example

Authentic output from that demo run:

static-link-sentinel: dist/ 3 page(s), 1 stylesheet(s), 7 file(s), 15 internal reference(s)

about.html
  ✖ error Broken internal link [broken-link]  line 12
          <a href="/pricing/"> resolves to no file in the build
          fix: Remove the link or create the page.

assets/style.css
  ✖ error Missing asset [missing-asset]  line 2
          ../img/bg.png resolves to no file in the build
          fix: Check the build output and asset paths (publicPath/base).

index.html
  ✖ error Broken internal link [broken-link]  line 16
          <a href="/blog/post-l/"> resolves to no file in the build
          fix: did you mean /blog/post-1/?
  ✖ error Path case mismatch [case-mismatch]  line 18
          <a href="/Blog/Post-1/"> only matches blog/post-1/index.html with different case (fails on Linux/CDN hosts)
          fix: Use /blog/post-1/ or rename the file
  ✖ error Path case mismatch [case-mismatch]  line 20
          <img src="/img/Logo.png"> only matches img/logo.png with different case (fails on Linux/CDN hosts)
          fix: Use /img/logo.png or rename the file
  ✖ error Missing asset [missing-asset]  line 22
          <img src="/img/hero-missing.png"> resolves to no file in the build
          fix: Check the build output and asset paths (publicPath/base).
  ⚠ warn  Missing #fragment anchor [missing-fragment]  line 24
          <a href="/about#tem">: no id="tem" in about.html
          fix: did you mean #team?

sitemap.xml
  ✖ error sitemap.xml URL not in build [sitemap-url]  line 6
          <loc>https://demo.example/gone/</loc> has no matching page in the build
          fix: Regenerate the sitemap or remove the entry

3 page(s) checked: 7 error(s), 1 warning(s), 0 info

Notice the "did you mean" hints: typo links and near-miss fragments get a Levenshtein-style suggestion instead of a bare failure. The case-mismatch lines are the ones source review usually misses, because the file "looks present" on a case-insensitive laptop.

Wire it into CI after the build

The cheapest habit is a postbuild script:

npm i -D static-link-sentinel

{
  "scripts": {
    "postbuild": "static-link-sentinel dist --site-url https://example.com"
  }
}

Or the GitHub Action after npm run build:

- uses: MrLouisWright/static-link-sentinel@v1
  with:
    dir: dist
    site-url: https://example.com
    fail-on: error
    sarif: links.sarif

Framework recipes follow the same pattern: run after vite build, next build (static export to out/), astro build, Eleventy, or Hugo, and pass --base-path when the site is served under a subpath. Vite and webpack plugins can attach the check to the bundler lifecycle so a bad build never exits green.

For outbound links, enable --external on a schedule or on push (not necessarily every PR) and cache .link-cache.json between runs so unchanged URLs are not re-fetched every time.

Limits worth knowing

Only static markup and assets are visible. Client-side routers and content injected by JavaScript after load are out of scope, and SPA fallbacks that rewrite every path to index.html make every route look "present." Soft 404s on remote hosts can still return HTTP 200. HTML is tokenized with an offset-preserving regex approach rather than a full HTML5 parser, so badly malformed markup may be misread. Those are honest boundaries, not marketing fine print.

Check the bytes you will serve

Pew's figures show broken links are common even on news and government pages [1]. Case-sensitive object stores will not forgive a capital letter that a laptop filesystem ignored [2]. Search systems treat soft 404s and redirect chains as crawl waste [3][4]. The practical response for a static site is simple: after the build, crawl the output, fail the job when references do not resolve, and fix the path before the CDN ever sees it.

Louis Wright

References

Chapekis, A., Bestvater, S., Remy, E., and Rivero, G. (Pew Research Center). "When Online Content Disappears". 2024. https://www.pewresearch.org/data-labs/2024/05/17/when-online-content-disappears/
Amazon Web Services. "Naming Amazon S3 objects". Amazon Simple Storage Service User Guide. Accessed Oct 2026. https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-keys.html
Google Search Central. "Troubleshoot crawling errors" (soft 404 errors). Accessed Oct 2026. https://developers.google.com/search/docs/crawling-indexing/troubleshoot-crawling-errors
Google Crawling Infrastructure. "Crawl budget management for site owners". Accessed Oct 2026. https://developers.google.com/crawling/docs/crawl-budget

CAPTCHAs Lost to AkiraBot on 80,000 Sites. Here Is Captcha-Free Form Protection

Louis Wright — Thu, 15 Oct 2026 04:14:15 +0000

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

In April 2025, SentinelLABS published research on AkiraBot: an AI-powered spam framework that targeted more than 420,000 websites and successfully spammed at least 80,000 of them since September 2024 [1]. It used OpenAI to generate custom outreach for each site, then pushed those messages into contact forms and chat widgets. The operators also invested heavily in defeating CAPTCHAs, including hCAPTCHA, reCAPTCHA, and Cloudflare Turnstile [1].

That is the uncomfortable part. The industry's most common "prove you are human" control is on the target list for commodity spam tooling. If CAPTCHA is optional for the attacker, what does a contact form owner actually have left?

Form spam is an automated threat, not a UX bug

OWASP lists form and content spam as OAT-017 Spamming in its Automated Threats taxonomy: automated addition of malicious or questionable content and messages, including SEO and form spam [2]. A related threat, OAT-009 CAPTCHA Defeat, covers the other side of the same fight: automation that solves or bypasses anti-automation puzzles with OCR, image databases, or human solver farms [3].

OWASP's Bot Management cheat sheet is blunt about visible CAPTCHAs: they are accessibility-hostile, increasingly machine-solvable, and available to solver farms for fractions of a cent [4]. The W3C's Inaccessibility of CAPTCHA note has made the same accessibility case for years: visual and audio challenges routinely exclude people who should still be able to use the form [5].

So the failure mode for a typical contact page stacks up like this:

A bot finds the form (or buys a target list).
It fills every field, including ones humans never see if the honeypot is weak or missing.
If there is a CAPTCHA, a bypass service or farm solves it.
Your inbox fills with SEO pitches, fake leads, or worse.

A puzzle in front of every visitor is the wrong primary control. You want checks that cost almost nothing for a real browser session and raise the price of bulk automation.

Cheap layers that bots fail

That is the design behind form-honeypot-guard, a captcha-free package I built for Node apps:

an off-screen, accessible honeypot field with a randomised, realistic name on each build;
an HMAC-signed timing token, so submissions that arrive too fast, too late, tampered, or replayed are rejected;
a JS proof field that only a real browser fills, plus light interaction signals (keypress, pointer, focus);
optional content heuristics (link spam, URLs in name fields, spam keywords);
sliding-window rate limiting per IP (and optionally per email or fingerprint), with a correct 429 and Retry-After;
optional Altcha-style proof-of-work when you want a stronger challenge without a captcha vendor.

The client runtime is under 2 kB gzipped. Webpack and Vite plugins inject the honeypot markup at build time, randomise field names, and write a manifest the server reads. Helpers cover Express/Connect, Fastify, Next.js, SvelteKit, Remix, Astro, and plain Fetch runtimes, plus an optional React wrapper.

Auditing built HTML with the CLI

Protecting forms is half the story. The other half is noticing when a form shipped without the trap. The CLI audits built HTML:

npx form-honeypot-guard check dist --strict

The demo below is made up for this article: two HTML files under demo/dist with an unprotected POST contact form, a newsletter form that accidentally uses GET (so the email would land in the query string), and one form that already looks partially guarded. Real output from version 1.1.1:

Two errors and two warnings:

a POST form with no honeypot;
a GET form that would put personal data in the URL;
CSRF token warnings on both POST forms (the checker reminds you; SameSite cookies alone are not always enough).

--strict treats warnings as errors and exits 1, which is what you want in CI. form-honeypot-guard secret prints a fresh HMAC secret for FORM_GUARD_SECRET.

Wiring the guard into a build

Mark forms with data-guard (or guard all of them), then add the webpack plugin:

const { FormGuardPlugin } = require('form-honeypot-guard/webpack');

new FormGuardPlugin({
  forms: 'form[data-guard]',
  secretEnv: 'FORM_GUARD_SECRET',
  minTime: 3000,
  manifestPath: 'server/form-guard.manifest.json',
});

On the server (Express example):

import { expressGuard, cleanFields } from 'form-honeypot-guard';

app.use(expressGuard({
  manifest: 'server/form-guard.manifest.json',
  paths: ['/contact'],
  rateLimit: { limit: 5, windowMs: 60_000, keys: ['ip', 'email'] },
}));

And in CI, after the frontend build:

- run: npm run build
- name: Audit forms for honeypot coverage
  run: npx form-honeypot-guard@1 check dist --strict

The takeaway

AkiraBot showed that LLM-written spam plus CAPTCHA bypass can hit hundreds of thousands of sites [1]. OWASP already treats form spam and CAPTCHA defeat as first-class automated threats [2][3], and both OWASP and W3C warn against leaning on visible CAPTCHAs as the main defense [4][5]. Layer cheap server-checked signals instead, and fail the build when a form ships unprotected.

References

Delamotte, A. and Walter, J. (SentinelLABS / SentinelOne). "AkiraBot | AI-Powered Bot Bypasses CAPTCHAs, Spams Websites At Scale". 2025. https://www.sentinelone.com/labs/akirabot-ai-powered-bot-bypasses-captchas-spams-websites-at-scale/
OWASP. "OAT-017 Spamming". OWASP Automated Threats to Web Applications. Accessed Oct 2026. https://owasp.github.io/www-project-automated-threats-to-web-applications/assets/oats/EN/OAT-017_Spamming.html
OWASP. "OAT-009 CAPTCHA Defeat". OWASP Automated Threats to Web Applications. Accessed Oct 2026. https://owasp.github.io/www-project-automated-threats-to-web-applications/assets/oats/EN/OAT-009_CAPTCHA_Defeat.html
OWASP. "Bot Management and Anti-Automation Cheat Sheet". Accessed Oct 2026. https://cheatsheetseries.owasp.org/cheatsheets/Bot_Management_and_Anti-Automation_Cheat_Sheet.html
W3C. "Inaccessibility of CAPTCHA: Alternatives to Visual Turing Tests on the Web". W3C Working Group Note. Accessed Oct 2026. https://www.w3.org/TR/turingtest/

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