Frontend Security Patterns

Production engineering guide for frontend security patterns covering patterns, implementation strategies, and operational best practices.

This reference page addresses the patterns and mechanisms that keep frontend codebases from becoming attack surfaces. It matters whenever code runs in a user’s browser, touches backend APIs, or processes untrusted data. The patterns here apply whether you are building a custom SPA, a server-rendered application, or a widget embedded in third-party pages. They are relevant at every stage: initial architecture, daily development, CI pipelines, and production incident response.

Preventing XSS in Markup Rendering

The most common entry point for frontend attacks is cross-site scripting. The pattern is to never trust data that originates outside your control—URL parameters, form inputs, JSON payloads, and browser local storage. The golden rule: escape as late as possible, and only in the specific context where the data appears.

When rendering HTML, entities must be encoded for the HTML context. A & becomes &amp;, < becomes &lt;, and so on. Most templating engines provide built-in helpers, but the escape function must be the final step in the rendering pipeline, not an afterthought.

<!-- Safe: hand off to the engine's escape -->
{{ userInput }}

<!-- Unsafe: raw HTML insertion -->
<div>{{ userInput | raw }}</div>

When injecting data into JavaScript variables, the HTML entity escape is insufficient. The string must be serialized for the JS context, typically via JSON.stringify or a dedicated escaping utility.

// Safe: JSON serialization escapes special characters
const script = `<script>var data = ${JSON.stringify(userInput)}</script>`;

// Unsafe: string concatenation allows injection
const script = `<script>var data = ${userInput}</script>`;

For event handlers, avoid inline onclick attributes with interpolated data. Attach listeners programmatically and pass data as arguments.

// Safe: event listener with data argument
element.addEventListener('click', () => handleClick(userInput));

// Unsafe: inline handler with interpolation
element.innerHTML = `<button onclick="handle('${userInput}')">Go</button>`;

Secure API Communication

Frontend code routinely talks to backends over HTTP. Every outbound request should include credentials only when necessary, and responses must be validated before processing.

Cross-origin requests require deliberate opt-in. Browsers enforce CORS by default, and the server must return an explicit Access-Control-Allow-Origin header that matches the requesting origin. A wildcard * is never appropriate when credentials are involved.

# Test CORS headers on a development endpoint
curl -I https://api.example.com/data
# Expected response includes:
# Access-Control-Allow-Origin: https://app.example.com
# Access-Control-Allow-Credentials: true

When sending cookies or authorization headers, set withCredentials: true on the request object, but only if the server explicitly permits it.

// Fetch with credentials
fetch('/api/profile', {
  credentials: 'include',
  headers: {
    'Content-Type': 'application/json'
  }
})

Response validation is where many failures occur. Never assume the shape of data returned from an endpoint. Define a schema (using a library such as Zod, AJV, or a hand-rolled guard) and reject requests that do not conform.

// Schema validation example (Zod)
const profileSchema = z.object({
  id: z.string().uuid(),
  name: z.string().min(1),
  email: z.string().email()
});

const response = await fetch('/api/profile', { credentials: 'include' });
const json = await response.json();

try {
  const validated = profileSchema.parse(json);
  // proceed with validated data
} catch (error) {
  // reject: response shape does not match expected schema
  console.error('Invalid profile data received');
}

Authentication and Token Management

Tokens—whether session cookies, JWTs, or opaque references—must be handled with care. The frontend should never generate or validate authentication tokens; that responsibility belongs to the auth service. The frontend’s role is secure transmission and renewal.

Refresh tokens should never be stored in localStorage. That location is accessible to any script running on the page, making it a target for XSS exfiltration. Prefer HttpOnly cookies for session tokens, or store refresh tokens in a secure, HttpOnly-cookie-compatible store such as document.cookie with the Secure and SameSite=Strict flags.

# Inspect cookie attributes set by the auth server
curl -v --cookie "session=abc123" https://app.example.com/dashboard
# Verify: Set-Cookie includes Secure, SameSite, and HttpOnly where applicable

Token renewal should occur transparently. When a request returns 401 Unauthorized, the client should attempt a refresh using a stored refresh token before presenting login credentials again. The refresh endpoint must invalidate the used refresh token and issue a new one, ideally with a shortened lifespan.

// Token renewal pattern
async function fetchWithRefresh(input, init) {
  let response = await fetch(input, init);
  
  if (response.status === 401) {
    const newTokens = await refreshAccessToken();
    if (newTokens) {
      init.headers.Authorization = `Bearer ${newTokens.accessToken}`;
      response = await fetch(input, init);
    }
  }
  
  return response;
}

Dependency Security

Frontend projects pull in dozens or hundreds of transitive dependencies. Each one is a potential vulnerability vector. Regular auditing is non-negotiable.

Run a lockfile audit as part of every CI build.

# npm audit run as part of CI
npm audit --production --audit-level=high

# yarn equivalent
yarn audit --production --level high

When a vulnerability is flagged, consult the advisory before upgrading. Some updates introduce breaking changes in API surface or build configuration. Patch upgrades (^1.2.3 → 1.2.4) are lowest risk; minor or major bumps require functional verification.

# Upgrade a single vulnerable package safely
npm update package-name@latest

# Or bump to the latest minor within the current major
npm install package-name@^2

Pin dependency versions in package-lock.json or yarn.lock. Do not rely on ranged versions (>=1.0.0) in production builds, as a new major release could introduce incompatible changes or supply-chain attacks.

Security Headers and CSP

HTTP response headers are the browser’s first line of defense against a range of attacks. Every frontend-served response should include a minimal, hardened set of headers.

X-Content-Type-Options: nosniff prevents the browser from MIME-type sniffing, forcing it to respect the Content-Type declared by the server.

X-Frame-Options: DENY (or SAMEORIGIN) prevents the page from being embedded in a frame on another site, mitigating clickjacking.

Content-Security-Policy is the most powerful but also the most complex header. A starter policy restricts sources to the same origin and explicitly allowed domains.

Content-Security-Policy: default-src 'self'; script-src 'self' https://scripts.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:;

The default-src 'self' directive is the safety net: if any other directive fails to match, the browser blocks the request. From there, whitelist only the sources your application actually needs.

Deploying CSP requires iteration. Start with Content-Security-Policy-Report-Only to monitor violations without blocking traffic. Review the reported violations in the browser’s dev tools or a dedicated endpoint, then tighten the policy incrementally.

# Test CSP report-only mode
curl -I -H "Content-Security-Policy-Report-Only: default-src 'self'" https://app.example.com

A common confusion is between unsafe-inline and unsafe-eval. unsafe-inline permits inline <script> tags and event handlers; unsafe-eval permits eval(), new Function(), and similar dynamic code execution. Both should be avoided in production. Inline scripts should be moved to external files, and dynamic code generation should be refactored away.

Sharp Edges — What Silently Fails

Several patterns break down under pressure, and the failure modes are not always obvious.

CSP misconfiguration with nonce-based inline scripts. When a page uses a nonce to allow specific inline scripts, the nonce value must be generated per-request and included in both the <script> tag and the CSP header. If the nonce generation fails or is cached incorrectly, the scripts silently stop executing, and debug logs offer no immediate clue.

CORS with credentials and wildcard origin. Setting Access-Control-Allow-Origin: * while also returning Access-Control-Allow-Credentials: true is rejected by browsers. The two are mutually exclusive. If a frontend needs both wild-card CORS and credential forwarding, the backend must reflect a specific origin rather than *.

Refresh token rotation pitfalls. Some auth implementations rotate the refresh token on every use, invalidating the previous one. If the frontend caches the token or retries a request after a network glitch, the cached token may already be invalid, causing repeated 401 responses and forcing a full login flow.

Cookie SameSite strictness. Setting SameSite=Strict prevents the browser from sending the cookie in top-level navigations from external sites. If your application legitimately needs to be embedded or linked from other domains, SameSite=Lax may be required, but it opens a smaller attack surface for CSRF. The choice must be deliberate and documented.

Dependency confusion. A malicious package published to a public registry with a name similar to an internal private package can hijack builds if the package manager resolves the public version first. Pin exact versions and, where possible, use a private artifact registry for internal packages.

Failure Modes Learned in Production

This page was rewritten on 18 October 2026. It replaced a templated version that was not specific to its own title. How these pages are written and checked. If anything here is wrong, tell us at [email protected] and we will correct it.