5chan/docs/agent-runs/codebase-audit-2026-04-23/03-security.md

Security Audit

Summary

5chan's React frontend has a generally defensive posture for an imageboard that renders untrusted peer content: zero dangerouslySetInnerHTML usages (prior scan confirmed), custom markdown tokenizer that leans on React's JSX escaping, target="_blank" links uniformly paired with rel="noopener noreferrer", and URL parsing routed through the browser URL constructor. The highest-impact issues are a severely broken crypto RNG polyfill that silently downgrades crypto.getRandomValues to Math.random, third-party embed scripts loaded into about:srcdoc iframes that inherit the 5chan origin without Subresource Integrity, and the complete absence of a Content-Security-Policy header — so any future XSS has no defense-in-depth to contain it. Several medium issues stem from peer-controlled URLs flowing into <img>, <video>, <audio>, <a href>, and iframe embedders without origin validation, which is acceptable for many decentralized imageboard designs but warrants an explicit allow-list or protocol filter.

Threat Surface Overview

Trust boundary	Where it enters the client	Key files
Peer post content (title, content, link, reason)	Subplebbit/community feeds via bitsocial-react-hooks	src/components/markdown/markdown.tsx, src/components/comment-content/comment-content.tsx, src/components/comment-media/comment-media.tsx, src/views/archive/archive.tsx
Peer-supplied media URLs	Comment link field	src/lib/utils/media-utils.ts, src/components/comment-media/comment-media.tsx, src/components/catalog-row/catalog-row.tsx, src/components/embed/embed.tsx
External iframe challenges (captcha)	challenge field of type url/iframe	src/components/challenge-modal/challenge-modal.tsx
External webpage thumbnails (og:image/first <img>)	Community-served link preview fetched via fetch()/CapacitorHttp	src/lib/utils/media-utils.ts (fetchWebpageThumbnail)
GitHub release manifest	api.github.com release JSON for auto-update	src/lib/app-update.ts, src/lib/app-update-config.ts
GitHub directories list	raw.githubusercontent.com JSON	src/hooks/use-directories.ts
Account data / private keys	bitsocial-react-hooks account store; editor reads/writes JSON including signer	src/views/account-data-editor/account-data-editor.tsx, src/components/settings-modal/account-settings/account-settings.tsx, src/lib/utils/account-editor-utils.ts
Local preferences	localStorage keys (filters, subscriptions, UI state)	src/stores/use-*-store.ts, src/hooks/use-directories.ts
URL query/hash routing	Location search/hash parsed via URLSearchParams/is5chanLink	src/lib/utils/url-utils.ts, src/components/catalog-search/catalog-search.tsx, index.html
User regex hide filters	User-typed patterns compiled via new RegExp	src/lib/utils/pattern-utils.ts
Native bridges	window.electronApi.* (copy clipboard, upload automation, installer)	src/globals.d.ts, src/hooks/use-file-upload.ts, src/lib/app-update.ts, src/lib/utils/clipboard-utils.ts

Findings

Critical

• src/polyfills.js:20-29 — window.crypto.getRandomValues is replaced with a Math.random()-backed fallback when window.crypto is undefined. Math.random is a non-cryptographic PRNG (typically xorshift/PCG seeded at startup, fully predictable). Anything that later calls crypto.getRandomValues under this polyfill — libsodium, noble-curves/ed25519, IPFS/libp2p key generation, nonces, session IDs inside bundled deps — silently produces guessable output. In modern browsers the branch shouldn't trip (crypto always exists), but the guard also short-circuits any environment where crypto exists but getRandomValues is missing (older SSR shims, some Electron preload corner cases), so the defensive posture is broken rather than safe-by-default. The severity is magnified because a decentralized imageboard derives account keypairs, signs publications, and derives author addresses from this primitive layer. Fix: remove the Math.random fallback entirely. If a host truly lacks crypto.getRandomValues, throw so callers bail; do not fabricate randomness. At minimum, guard the replacement behind a build-time flag so it never ships to production.

High

• src/components/embed/embed.tsx:113-315 — Third-party embed scripts (platform.twitter.com/widgets.js, embed.reddit.com/widgets.js, www.tiktok.com/embed.js, //www.instagram.com/embed.js) are injected via srcDoc iframes with no sandbox attribute and no Subresource Integrity hash. An about:srcdoc iframe inherits the embedding document's origin, so any script it loads executes as 5chan.app and can reach window.parent.document. A supply-chain compromise of any of those four CDNs (or a routed MITM on a user without HSTS) directly yields full XSS of the 5chan app, including read/write of IndexedDB account keys. This is amplified by the //www.instagram.com/embed.js scheme-relative URL, which downgrades to http:// if the top-level page is ever served non-TLS (Electron file://, local dev). Fix: (a) add sandbox="allow-scripts allow-popups allow-same-origin" carefully chosen per embed type so cross-origin script compromise cannot reach parent; ideally omit allow-same-origin and rely on the iframe being a true opaque origin; (b) pin src="https://..." absolute for Instagram; (c) consider inlining the embed via the official oEmbed server-side rendering path or proxying through a CSP-constrained iframe host (e.g. a sandbox subdomain).
• index.html (entire file) + vercel.json:36-45 — No Content-Security-Policy header is emitted and no <meta http-equiv="Content-Security-Policy"> exists. Given that the primary threat model is untrusted peer content and third-party scripts load into the origin via srcdoc iframes, a CSP is the most impactful missing control. A single XSS bypass (today, future regression, or supply-chain) would have full DOM access. Fix: add a strict CSP via Vercel header: default-src 'self'; script-src 'self' 'wasm-unsafe-eval'; frame-src https:; img-src https: data: blob:; media-src https: blob:; connect-src 'self' https: wss:; style-src 'self' 'unsafe-inline'; object-src 'none'; base-uri 'none'; form-action 'none'; frame-ancestors 'none'. Tighten over time (drop 'unsafe-inline' for styles once CSS-modules replaces any inline styles). Mirror with Strict-Transport-Security: max-age=31536000; includeSubDomains and, since the app is hash-routed, consider Cross-Origin-Opener-Policy: same-origin and Cross-Origin-Resource-Policy: same-origin to block spectre-style side-channels.
• src/components/comment-media/comment-media.tsx:74, 89, 93, 108, 124, 138, 218, 235, 238, 349, 388; src/components/catalog-row/catalog-row.tsx:84-101 — Peer-supplied url / thumbnail / gifFrameUrl are rendered directly as <img src>, <video src>, and <audio src> with no scheme or host allow-list. getLinkMediaInfo only validates that new URL(link) succeeds (src/lib/utils/url-utils.ts:13-20), so javascript:foo parses successfully and flows through. React auto-strips javascript: for href and src on <a>/<iframe>/<script>/<form> (since React 16.9), but <img src="javascript:…"> is a no-op in modern browsers and <video src>/<audio src> likewise ignore javascript URLs — so the immediate XSS risk is low — however data: URIs and oversized blob:/file: URIs are not filtered, which lets a malicious community: (1) use data:image/svg+xml,<svg onload=…> style SVGs (browsers suppress script execution in <img src>-loaded SVGs but still fetch, and the stored-URL pattern becomes dangerous if ever rendered via <object> or <iframe>), (2) trigger unbounded memory via data: URLs, or (3) exfiltrate the visitor's IP to arbitrary servers simply by being rendered. Fix: in getLinkMediaInfo, reject URLs whose protocol is not https: or http: (and optionally ipfs:/ipns: for decentralized use). Extend the same check to thumbnail and patternThumbnailUrl. Consider routing all peer media through a rewrite that enforces protocol and normalizes origin.

Medium

• src/lib/utils/media-utils.ts:149-209 (fetchWebpageThumbnail) — Peer-supplied URLs are fetched directly by the client with no hostname filtering. This is a browser-side SSRF amplifier: a malicious community can set link to a private-range URL (http://192.168.1.1/…, http://169.254.169.254/…, intranet hosts, etc.) that the visitor's browser will fetch, parse, and extract an og:image or <img src> from — then render that extracted URL as <img src={thumbnail}>. On native (CapacitorHttp) this bypasses CORS entirely, so the attacker can probe arbitrary intranet resources and exfiltrate the response's first og:image/first image through cached thumbnail storage. Fix: reject private-range/link-local hostnames before fetch, require https:, and strip the extracted thumbnail URL down to https: only. Set an AbortController timeout shorter than the current 5 s on native, and never cache a thumbnail whose hostname differs from the source link's registered domain.
• src/components/challenge-modal/challenge-modal.tsx:27 — ImageChallenge renders data:image/png;base64,${challenge} where challenge is a peer-supplied string. React escapes the attribute so breakout is not possible; however there is no size or base64-sanity check, so a community can ship a multi-megabyte "challenge" that exhausts the decoder, or a non-PNG payload that fails silently and presents a broken image (usability, not XSS). Fix: validate challenge is /^[A-Za-z0-9+/=]{0,2000000}$/ before rendering; cap byte length; optionally decode with atob and sniff the PNG magic number.
• src/components/challenge-modal/challenge-modal.tsx:81-184 — IframeChallenge accepts a peer-provided URL, allows HTTPS plus any localhost / 127.0.0.1 / [::1] HTTP URL, and then hands it to an iframe with sandbox="allow-scripts allow-forms allow-popups allow-same-origin allow-top-navigation-by-user-activation". allow-same-origin + allow-scripts + allow-top-navigation-by-user-activation is a well-known dangerous combination: the iframe inherits 5chan origin (well, it's a cross-origin iframe so allow-same-origin only gives it its own origin back, not 5chan's — this is OK), but allow-top-navigation-by-user-activation lets the challenge redirect the top frame after a click, enabling phishing attacks disguised as challenges. The localhost exemption also lets any community probe services listening on the user's machine. Fix: drop allow-top-navigation-by-user-activation; either drop the localhost exemption or scope it to an explicit allow-list of known bitsocial services (and show a louder UI warning). Enforce a Permissions-Policy on the iframe (e.g. allow="").
• src/lib/app-update-config.ts:26-30 — isAllowedDownloadUrl accepts any URL whose hostname is exactly github.com (and any additional hosts via VITE_APP_UPDATE_ALLOWED_DOWNLOAD_HOSTS, which is permitted to be http:). GitHub release asset downloads begin at github.com/{owner}/{repo}/releases/download/… and redirect to objects.githubusercontent.com; the native updater may or may not follow that redirect, and an attacker who compromises the Releases API response can return an arbitrary browser_download_url pointing at github.com/<attacker>/<repo>/releases/download/…/evil.exe. Because the check is hostname-only, any github.com owner suffices. Fix: tighten to hostname === 'github.com' && url.pathname.startsWith('/bitsocialnet/5chan/releases/download/'). Also drop the http: fallback in the configuredDownloadHosts branch.
• src/lib/utils/pattern-utils.ts:34 — User-authored regex filters (/pattern/flags) are compiled with new RegExp(regexPattern, flags). Although these are user-typed for their own client, a combination of a pathological pattern like /(a+)+$/ and peer content can lock the UI (ReDoS). Fix: wrap the regex.test call in a worker with an execution budget, or reject patterns that fail a complexity heuristic (nested quantifiers, >1000 chars). Low urgency since only the user harms themselves.
• src/components/settings-modal/account-settings/account-settings.tsx:101 — Export filename comes from account?.name ?? 'account' with no sanitization before being assigned to link.download. account.name is user-controlled, so a user (or imported backup) with a name like ../../etc/passwd.json or one containing control characters would produce an odd download, and some browsers historically honored path separators. Low severity (self-inflicted, browsers normalize), but worth stripping. Fix: link.download = (account?.name || 'account').replace(/[^\w.\-]/g, '_') + '.json'.
• src/components/post-desktop/post-menu-desktop/post-menu-desktop.tsx:147-154 and src/components/post-mobile/post-menu-mobile/post-menu-mobile.tsx:148-155 — Reverse-image-search URLs interpolate peer url directly into a template: `https://lens.google.com/uploadbyurl?url=${url}`, saucenao.com/search.php?url=${url}, yandex.com/images/search?img_url=${url}. No encodeURIComponent; because url came from new URL(), dangerous characters like ", <, # are percent-encoded, but & is not, letting a crafted URL add extra query parameters to the third-party site (e.g. & followed by rogue query keys). Not a traditional XSS but a minor integrity/tracking concern. Fix: encodeURIComponent(url) in all three places.
• src/components/comment-media/comment-media.tsx:163 — <a href={url} target='_blank' rel='noreferrer'> uses rel='noreferrer' only. Modern browsers treat noreferrer as implying noopener, but older targets (some WebKit variants, older Android WebViews used via Capacitor) do not. Fix: standardize on rel='noopener noreferrer' like the other 20+ occurrences in the codebase.
• src/views/account-data-editor/account-data-editor.tsx:85-98 — The account JSON editor accepts free-form JSON and writes it back via setAccount. A hostile paste (e.g. a phishing "here's your key, paste this") is handed straight to the hook layer. No warning about what fields are dangerous (e.g. signer.privateKey, subscriptions), and the error surface is a plain alert(e.message) which could leak library internals. Fix: enumerate expected fields; warn or refuse to import JSON that mutates signer to a different address than the current account.

Low

• src/stores/*-store.ts — Many stores persist to localStorage (subscriptions, filters, catalog style, disclaimer acceptance, popular threads options, directories cache). None of this is secret, so plaintext is fine; however the underlying account store used by bitsocial-react-hooks likely persists the signer (private key) to IndexedDB unencrypted. That's upstream of this repo, but it means any XSS trivially exfiltrates identity. Document the threat model and consider an optional passphrase-encrypted vault for key material.
• src/components/settings-modal/account-settings/account-settings.tsx:84, 166 — console.log(error) of whole Error objects during account export/import error paths. If the error chain from exportAccount() ever includes the raw account JSON (it shouldn't, but is library-dependent), that lands in devtools. Fix: log error.message only.
• src/components/comment-media/comment-media.tsx:144 — new URL(url) is constructed in the middle of render (linkWithoutThumbnail = url && new URL(url)). If url is malformed the component throws and unmounts the subtree. A malicious peer can crash rendering of a thread by posting a comment with a link value like "not a url". Fix: use isValidURL guard before constructing.
• index.html:64-76 — Initial-load redirect synthesizes '/#' + window.location.pathname + window.location.search and calls window.location.replace. Same-origin-only, so this is not an open redirect, but pathname could contain arbitrary characters (via DNS or server rewrite) that end up in the hash. Low risk given router validation, but worth normalizing.
• src/components/embed/embed.tsx:163,166 — parent=${window.location.hostname} passed to the Twitch player. The hostname is trusted (it's the 5chan origin), but Twitch's embed documentation requires each parent domain to be pre-registered on the Twitch side; a hostname mismatch causes silent failure. Not a security bug but a reliability footgun when the app runs on alt hostnames (5chan.eth.limo, Electron file:).
• src/sw.ts — Service worker uses NetworkFirst for navigations and StaleWhileRevalidate for assets. No validation that cached responses originated from the 5chan origin (the Workbox defaults enforce that via same-origin registerRoute), so lookup semantics are fine. However an XSS on 5chan can seed the SW cache with a poisoned response and pin it for up to 30 days (maxAgeSeconds: 60 * 60 * 24 * 30). Fix: once CSP is in place, also add self.registration.unregister() + cache wipe on startup if the SW detects a version mismatch.
• src/lib/media-hosting/* — Uploads POST peer files to catbox.moe and imgur. No hash pinning or response sanitization; the returned URL (text body) is trusted verbatim and flows back into <img src>. A compromised host can substitute URLs pointing at attacker content, but the user chose to upload there, so this is expected risk. Document it.
• Static analysis confirmations (no issue found) — dangerouslySetInnerHTML usages in src/: 0. document.write: 0. eval / new Function: 0. innerHTML =: only in __tests__. All target="_blank" anchors have rel attributes (the handful with only noreferrer are noted above). matchesPattern uses RegExp only on the user's own inputs. The custom markdown tokenizer renders every text/URL/quote token through JSX children (React-escaped); no raw HTML is produced.

Top 5 Actions

1. Remove the Math.random fallback in src/polyfills.js (and rebuild). This is a latent crypto-weakness with catastrophic blast radius if ever exercised.
2. Add a Content-Security-Policy header in vercel.json (and a <meta> fallback for Electron/IPFS hosting) that restricts script-src to 'self' plus the specific embed CDNs, and constrains frame-src/img-src/media-src/connect-src to the actually-used origins. Pair with HSTS.
3. Harden the third-party embed pipeline in src/components/embed/embed.tsx: add sandbox attributes to every srcDoc iframe, pin Instagram to absolute https://, and (ideally) move the external-script embeds to a dedicated sandbox origin so widgets.js compromises cannot reach the parent.
4. Add a protocol allow-list in getLinkMediaInfo/isValidURL (src/lib/utils/url-utils.ts, src/lib/utils/media-utils.ts) so only http:/https: (and intentionally supported ipfs:/ipns:) URLs flow into <img>/<video>/<audio>/<a href> and into fetchWebpageThumbnail. Reject private-range hostnames in the thumbnail fetcher to close the browser-side SSRF.
5. Tighten isAllowedDownloadUrl (src/lib/app-update-config.ts) to require the github.com path prefix of the official release repo, and drop the http: permission in the configurable-hosts branch. Bundle this with a sandbox hardening of IframeChallenge (drop allow-top-navigation-by-user-activation, reconsider the localhost exemption).