zenveil explain

zenveil explain <finding_id>

# Explain a finding
zenveil explain ZV-A1B2C3

Explaining ZG-E5F6: Token stored in browser storage

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

What this is:
Your application is storing an authentication token in localStorage at
src/auth/login.js:8. Specifically, the code reads:

  localStorage.setItem('auth_token', token);

Why it matters:
localStorage is accessible by any JavaScript running on the same
origin — including injected scripts from XSS vulnerabilities, browser
extensions, and third-party analytics scripts. If an attacker finds
even a minor XSS vulnerability anywhere on your site, they can steal
this token, impersonate your user indefinitely, and bypass logout.

This maps to OWASP A02:2021 (Cryptographic Failures) and A07:2021
(Identification and Authentication Failures). It's one of the most
commonly exploited patterns in modern web applications.

Real-world impact:
In 2022, a major SaaS platform suffered a breach because tokens stored
in localStorage were exfiltrated via a third-party script. The attacker
maintained persistent access to 40,000 accounts for 3 months.

The fix:
Use an httpOnly, Secure, SameSite=Strict cookie issued by your server:

Server-side (Node.js/Express):
  res.cookie('session', token, {
    httpOnly: true,   // Cannot be read by JavaScript
    secure: true,     // HTTPS only
    sameSite: 'Strict', // No cross-origin sending
    maxAge: 3600000,  // 1 hour
  });

Client-side:
  // Remove the localStorage.setItem call entirely
  // The cookie is managed automatically by the browser

If you must use client-side storage (e.g., for a SPA with no server),
use sessionStorage instead of localStorage (clears on tab close) and
implement XSS protection rigorously.

Confidence: 80% · OWASP: A02:2021, A07:2021
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━