DEV Community: Gyu

No backend, no database, no network calls. I still found 3 security holes.

Gyu — Sun, 26 Jul 2026 10:14:03 +0000

No server. No database. No login. No network calls at all. One index.html file, no build step. You open it in a browser, drop in some images, export, done.

So when I sat down to audit it before pushing an update, I figured this would be quick. There's barely anything to attack.

I found three things. None of them were in the rendering code, the canvas code, or anywhere I expected. They were all in the same place: the function that opens a project file.

This is an English write-up of an article I posted on Zenn, restructured a bit for a different audience.

The setup

The tool makes App Store screenshots. The relevant feature: it saves your whole deck — text, images, styling — into a single .json file, so you can pick up where you left off later, or hand it to someone else.

That last part turned out to be the whole story.

1. A shared file could phone home

Here's what the loader looked like:

// before
DEVS.forEach(dev => {
  const src = sd.img && sd.img[dev];
  if (src) { const im = new Image(); im.src = src; }
});

When I save a file, every image is written out as data:image/png;base64,.... So when reading one back, it'll be a data URL. Obviously.

Except a .json file is just text, and whoever has it can edit it:

{ "style": { "bgImg": "https://attacker.example/beacon.png?id=abc" } }

Open that file and the browser goes and fetches it. The person on the other end gets your IP, your User-Agent, and a timestamp telling them you opened it. Nothing appears on screen. One image silently fails to load. There's nothing to notice.

It's not RCE and it's not data exfiltration. But this tool's entire pitch is "runs locally, nothing is uploaded, no tracking" — and opening one file from someone else quietly breaks that. Less a severity problem, more a "the thing I promised isn't true" problem.

The fix is a scheme allowlist:

const IMG_DATA_RE = /^data:image\/(png|jpe?g|gif|webp|avif|svg\+xml);base64,[A-Za-z0-9+/=\s]+$/i;
function safeImgSrc(v){ return (typeof v === "string" && IMG_DATA_RE.test(v)) ? v : null; }

Inline data: images pass. Everything else becomes null. I ran every image path through it — background image, logo overlay, and the per-device screenshots.

Worth grepping your own code for: img.src, fetch, a.href, link.href, CSS url(), iframe.src. Any file-derived string reaching those, and no scheme check? Same hole.

2. `Object.assign` + `JSON.parse` = prototype pollution

Same function, one line up:

// before
if (d.style) Object.assign(state.style, d.style);

Looks like a completely ordinary merge. There's a trap in this specific pairing:

JSON.parse('{"__proto__":{...}}') produces an object with __proto__ as an own property. The setter is not invoked here.
Object.assign copies using [[Set]] — equivalent to writing target.__proto__ = {...}. Now the setter fires.

Result: the target's prototype gets swapped for whatever the attacker supplied. It's not Object.prototype-wide pollution, so the blast radius is limited, but keys I never defined start showing up in in and for...in.

Object.assign also doesn't check anything else. titleSize: 999 goes straight through. So does bg1: "red;background:url(...)".

So I dropped the merge and rebuilt each known key by hand:

function sanitizeStyle(r){
  if (!r || typeof r !== "object") return;
  const s = state.style;
  s.bgType    = safePick(r.bgType, ["gradient","solid","image"], s.bgType);
  s.bg1       = safeHex(r.bg1, s.bg1);
  s.titleSize = safeNum(r.titleSize, 0.01, 0.3, s.titleSize);
  s.bgImg     = safeImgSrc(r.bgImg);
  // ...known keys only
}

__proto__ now just falls through as an unknown key. Numbers get clamped, colors get format-checked. Not "reject the dangerous keys" — only pick up the safe ones.

If you're hand-rolling a deep merge, or using structuredClone on parsed input, same question applies. You can also move to Object.create(null) or explicitly strip __proto__, but narrowing to known keys is the version I can read six months from now.

3. I trusted the types

I'd written the types. I just never checked the values at runtime.

// before
if (tt) s.loc[L] = { title: tt.title || "", subtitle: tt.subtitle || "" };

|| "" was supposed to mean "empty becomes an empty string." But if title is 12345, the number sails right through. The render path calls title.trim(), so you get trim is not a function and the app dies on the spot. {} does the same thing.

TypeScript wouldn't have saved me here either — JSON.parse returns any, and types don't exist at runtime.

Counts had the same gap. The editor caps you at 10 slides. Through a file, you could hand it 50,000.

// after
state.slides = d.slides.slice(0, 10).map(sd => {   // same cap the editor enforces
  ...
  s.loc[L] = { title: safeStr(tt.title, 500), subtitle: safeStr(tt.subtitle, 500) };
});

Obvious in hindsight: UI validation is a property of the UI, not of your data.

The bonus: a plain bug

Not a vulnerability, just broken:

// before
if (d.device === "iphone" || d.device === "ipad") state.device = d.device;

This tool started with two devices. It now has seven — Android phone, iPhone 6.7″, Android tablet, Mac, Play feature graphic. I'd already refactored the export pipeline to iterate a shared DEVS list. This one line never got updated.

So: work on the Mac layout, save, reload the file, and you're silently back on iPhone. No error, no warning.

// after
if (DEVS.includes(d.device)) state.device = d.device;

I only caught it because the audit made me list every field coming out of the file and write down what validated it. A security inventory turning up ordinary bugs is pretty common, in my experience.

What was already fine

Auditing isn't only about finding holes — confirming the clean parts is half the value.

XSS: none. User text hits innerHTML in exactly one spot (the slide list chips) and it was already escaped. Text-node position, so escaping & < > " is sufficient. I made the helper non-string-safe and added ' while I was there.
eval / new Function / string setTimeout: zero.
External resources: zero. No CDN, no analytics, no web fonts — the CJK fonts are bundled.
CSS injection: unreachable. There are style.background writes, but only internal constants flow into them.
ZIP paths: safe. Entry names are {locale}/{device}_{NN}.png, both from internal constants. No user string in the path, so no ../.

Making "no network" provable, not just promised

On top of the fixes, I added a CSP meta tag:

<meta http-equiv="Content-Security-Policy" content="
  default-src 'none'; img-src 'self' data: blob:; font-src 'self';
  style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline';
  connect-src 'none'; base-uri 'none'; form-action 'none'">

The important bit is that img-src has no http(s). If a future refactor loses the validation, the browser blocks the outbound fetch anyway. connect-src 'none' closes fetch, XHR and WebSockets.

The whole app is one inline script, so 'unsafe-inline' has to stay. I'm fine with that trade — what I care about protecting here is "nothing leaves the machine," not "injected script can't run," and there's no injection vector to begin with.

The side effect is nicer than the fix: "we don't track you" is a claim you have to take my word for. A CSP is something anyone can verify with the Network tab open.

Re-running the same attacks

I don't consider a fix done until the original attack is re-run. So I built one malicious project file with everything in it and threw it at the app:

Attack	Before	After
`bgImg` set to a remote URL	fetched it	`null`, zero requests
`__proto__` injected	prototype swapped	dropped as unknown key
`titleSize: 999`	applied as-is	clamped to 0.3
tags in a font name	accepted	default kept
50 slides	all 50 built	capped at 10
numeric title	threw on `.trim()`	coerced to `""`
save on Mac, reload	reverted to iPhone	stays on Mac

Network tab: zero requests. Console: no errors.

And the part that's easy to skip — I checked that a legitimate file still works. All six screenshots, styling, device and Japanese text survived the round trip, and export still hits spec (1284×2778, PNG color type 2, no alpha). Hardening that breaks the feature isn't hardening.

The takeaway

I had the threat model backwards. I kept thinking about the network, because that's where input usually comes from. But this app's trust boundary was the file.

The moment your app can open something a user obtained elsewhere, that's external input. .json, .csv, config files, export/import, "restore from backup." The trap is the sentence "my app wrote this file, so I know what's in it." You wrote it. Someone else is handing it back.

If you want the three-line version:

Find every place a file-derived string becomes a URL. Allowlist the scheme.
Don't Object.assign parsed JSON onto real state. Rebuild known keys.
Whatever the UI enforces — types, lengths, counts — enforce it again on the file path.

One more thing, since a lot of us are shipping AI-written code now: models write the save and the load together, and the loader ends up assuming the saver's output. It'll cheerfully trust its own format. That's not something the model flags — you have to.

The tool is on GitHub (MIT) if you want to look at the actual diff.

Has anyone found something interesting in their own import path? I'm curious whether the Object.assign one is as common as I suspect.

Electron's docs quietly dropped their recommended security tool. What now?

Gyu — Wed, 22 Jul 2026 13:41:36 +0000

Electron's docs quietly dropped their recommended security tool. What now?

If you've worked on an Electron app, you've probably seen the security checklist in the official docs. Until recently, that page also pointed to a static analysis tool called Electronegativity to help you check it automatically.

That recommendation is gone.

PR: electron/electron#48878 "docs: remove electronegativity"
Closes: electron/website#906

So right now, the docs just say "here are 20 items, check them by hand, and keep checking them on every release" — no tool recommendation at all.

This post covers what got removed, why, what you can use instead today, and (if you don't want to add a tool) the five spots worth checking by hand, with code.

This is an English write-up of an article I posted on Qiita, expanded a bit for a different audience.

Why it got removed

Electronegativity was released by Doyensec back in 2019 — an OSS tool that parses AST and DOM to catch Electron-specific misconfigurations and anti-patterns. For years it was the one tool the official docs pointed to.

Problem: feature development stopped around 2022. The repo itself says it's no longer being actively maintained, and it doesn't reliably keep up with newer Electron versions.

There was a paid successor, ElectroNG ($688/year, launched 2022), but that's not for sale anymore either — the buy page now just says to email them if you're interested in acquiring the source and infrastructure.

So the entire "dedicated Electron static analysis tool" slot is empty right now.

What can you use instead

Here's what I found when I went looking for what to actually run in CI.

CodeQL

General-purpose, but its standard query set includes some frameworks/electron queries that cover a handful of Electron-specific sinks. If you're already running CodeQL, this is close to free. It's not built around the Electron checklist specifically though, so don't expect full coverage.

Semgrep

You can write your own rules for individual checklist items. This works well in practice — writing a handful of narrow rules for the exact things that bit your app is a solid, low-effort first move.

One catch: dataflow analysis (taint tracking) in the free tier only works within a single function's scope. Cross-function/cross-file taint tracking is a paid Pro feature.

What general tools miss

ESLint plugins, npm audit, Snyk — these catch dependency CVEs and general JS lint issues just fine. What they don't catch, as a group, is the stuff specific to Electron's process model: misconfigured webPreferences, unsafe things exposed from preload, IPC handlers that don't validate their input.

Five things worth checking by hand

Whether or not you add a tool, these are the spots I'd actually look at in review.

1. webPreferences

The basics, and also where most apps get bitten.

// dangerous
new BrowserWindow({
  webPreferences: {
    nodeIntegration: true,
    contextIsolation: false,
  },
});

This gives the renderer direct access to Node. One XSS and you're looking at filesystem access or command execution.

// fixed
new BrowserWindow({
  webPreferences: {
    nodeIntegration: false,
    contextIsolation: true,
    sandbox: true,
    preload: path.join(__dirname, "preload.js"),
  },
});

Worth noting: Electron's own docs say nodeIntegration: false alone isn't enough — you need contextIsolation: true alongside it to actually block Node primitives. Treat these two as a pair.

Also, contextIsolation has been the default (true) since Electron 12, and sandbox since Electron 20. If you're on a reasonably current version and haven't explicitly turned these off, you're probably fine here already. The thing worth flagging in review is someone deliberately turning them off.

2. Inconsistent settings across windows

This is the one I think gets missed most often.

Main window is configured safely, but a child window creation site somewhere else in the codebase isn't.

// main window: safe
const mainWindow = new BrowserWindow({
  webPreferences: { contextIsolation: true, nodeIntegration: false },
});

// child window: got sloppy
ipcMain.handle("open-win", (event, arg) => {
  const child = new BrowserWindow({
    webPreferences: { nodeIntegration: true, contextIsolation: false },
  });
});

If you only check the main window, you'll miss this every time. Worth diffing all the BrowserWindow creation sites in a project against each other, not just eyeballing the "main" one.

3. Command execution, especially with privilege escalation

Highest severity item on this list, full stop.

// dangerous: untrusted value interpolated into a shell command,
// combined with privilege escalation
sudo.exec(`networksetup -setdnsservers Wi-Fi ${userInput}`, options);

If userInput isn't validated, an attacker gets arbitrary command execution with admin privileges. Combined with something like sudo-prompt, the blast radius is the whole machine.

// fixed: args as an array, no shell involved
execFile("networksetup", ["-setdnsservers", "Wi-Fi", validatedInput], options);

execFile with an array of arguments means the value never gets re-interpreted as part of a command — as long as you don't pass shell: true, which routes it back through a shell anyway.

4. CSP

default-src 'self'; script-src 'self' 'unsafe-inline'

unsafe-inline or unsafe-eval in your CSP is a hole in your XSS defenses. A wildcard * in a source list is the same problem.

If you're writing a checker for this yourself: don't naively string-match for *, or you'll flag partial wildcards like *.example.com as false positives. Tokenize the CSP properly — split on ; for directives, then on whitespace for sources.

5. shell.openExternal

// dangerous: no scheme validation
shell.openExternal(urlFromRenderer);

Pass anything other than http/https (say, a file: URL) and you can end up opening something you didn't intend to.

// fixed: validate scheme against an allowlist
const parsed = new URL(urlFromRenderer);
if (parsed.protocol === "https:" || parsed.protocol === "http:") {
  shell.openExternal(urlFromRenderer);
}

Same idea applies to setWindowOpenHandler and will-navigate — worth checking whether you're actually controlling navigation there too.

If you want to automate this

Everything above is "remember to check this on every PR," which, honestly, doesn't hold up well in practice. A 40-file PR lands on a Friday afternoon and that one webPreferences line gets missed. That's a CI problem, not a human-vigilance problem.

So automating even a narrow slice of this is worth it. As mentioned above, writing 3-4 Semgrep rules for the specific things that have actually bitten your app is a good, cheap first step.

Full disclosure since this is relevant: I've been building an OSS tool in this space called electron-audit — parses JS/TS with Babel, never runs your app, outputs SARIF. The thing I cared about most is not becoming the boy who cried wolf: every finding carries a confidence (high vs. heuristic) separate from severity, and the CI exit code only fails on high-confidence critical/high findings — so the softer, heuristic dataflow-based findings get reported but don't block your build.

https://github.com/gyugyu86/electron-audit

If you know of other tools trying to fill this same gap, genuinely curious — would like to hear about them.

tl;dr

Electron's docs removed the Electronegativity recommendation (#48878)
Reason: Electronegativity is unmaintained, and its paid successor ElectroNG isn't for sale anymore either
Right now there's no tool the docs point you to
Alternatives: CodeQL (general-purpose, a few Electron-specific queries), Semgrep (free tier taint is single-function only), or newer community OSS
If you're not adding a tool, at minimum check: webPreferences, cross-window setting consistency, command execution, CSP, and openExternal

The checklist itself isn't hard. Keeping it enforced release after release is the actual problem.

DEV Community: Gyu

No backend, no database, no network calls. I still found 3 security holes.

The setup

1. A shared file could phone home

2. Object.assign + JSON.parse = prototype pollution

3. I trusted the types

The bonus: a plain bug

What was already fine

Making "no network" provable, not just promised

Re-running the same attacks

The takeaway

Electron's docs quietly dropped their recommended security tool. What now?

Electron's docs quietly dropped their recommended security tool. What now?

Why it got removed

What can you use instead

CodeQL

Semgrep

What general tools miss

Five things worth checking by hand

1. webPreferences

2. Inconsistent settings across windows

3. Command execution, especially with privilege escalation

4. CSP

5. shell.openExternal

If you want to automate this

tl;dr

2. `Object.assign` + `JSON.parse` = prototype pollution