FSD Frontend System Design

Part II — The Shield · Lesson 3.5

Client-side Security

In one lineThe client is fully controlled by the user — it can enforce nothing and keep no secret.

Where you've seen itREACT_APP_API_KEY in a .env file, inlined into main.js at build time, readable by anyone who opens the Sources tab.

  • Time15 min
  • DiagramWhat the user can change vs what the server must re-check
  • Chapter3 · Security

Diagram

diagram
WHAT THE USER CONTROLS — all of it

  ┌───────────────────────── Their machine ──────────────────────────┐
  │  your JS bundle      readable, editable, breakpointable          │
  │  network requests    replayable in curl, headers rewritable      │
  │  localStorage        open in DevTools                            │
  │  React state         editable via extensions                     │
  │  "disabled" button   removed with one DOM edit                   │
  └──────────────────────────────────────────────────────────────────┘
                              │
                              ▼  every request is attacker-shaped
  ┌──────────────────────────────────────────────────────────────────┐
  │  YOUR SERVER — the only place a rule is actually enforced        │
  └──────────────────────────────────────────────────────────────────┘
diagram
CLIENT CHECK vs SERVER CHECK — both, for different reasons

  Client validation   = user experience   (instant feedback)
  Server validation   = security          (the actual gate)

  Hiding an admin button      ✓ tidy UI
  Blocking /api/admin         ✓ the real control
diagram
TOKEN STORAGE — pick your poison

                      XSS-readable   CSRF-prone   effort
  localStorage             YES           no        low
  memory (JS variable)     YES           no        medium   lost on reload
  HttpOnly cookie          NO            YES       medium   SameSite fixes CSRF

  Best default: HttpOnly + Secure + SameSite=Lax cookie,
                short-lived access token, refresh rotated server-side.

How it works

  1. Assume the bundle is public. Anything in it — keys, endpoints, feature flags, business logic — is disclosed.
  2. Keep real secrets on the server. If the browser must call a third-party API with a secret, proxy it through your backend.
  3. Publishable keys are fine (Stripe publishable key, Maps key) — but restrict them by referrer, origin, and scope in the provider's console.
  4. Re-check every authorisation on the server. Hiding UI is presentation; the endpoint is the boundary.
  5. Don't rely on obfuscation or minification. It slows a reader by minutes, not attackers.

Trade-offs

Frontend canFrontend cannot
Improve UX with fast validationEnforce authorisation
Reduce blast radius (CSP, HttpOnly)Keep a secret
Rate-limit gently (debounce)Prevent request replay
Hide UI for unauthorised rolesPrevent access to the API

Interview angle

"Where do you store the JWT?"

  • Not localStorage if you can avoid it: any XSS reads it instantly.
  • Prefer an HttpOnly; Secure; SameSite=Lax cookie, which XSS cannot read, and handle CSRF separately.
  • Keep access tokens short-lived with server-side refresh rotation, so a stolen token has a small window.

Recap

  • Every client-side check is a hint; every server-side check is the rule.
  • Nothing shipped to the browser is secret — proxy anything that must stay private.
  • Token storage is a trade between XSS exposure and CSRF exposure; HttpOnly + SameSite handles both.