client-side-security

name	client-side-security
description	Apply when reviewing or writing browser-facing code that handles user input, renders HTML, sets cookies, or loads third-party scripts. Covers XSS, CSRF, CSP, clickjacking, XS-Leaks, and HTTP security headers.
license	CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/)
origin	Adapted from CoSAI Project CodeGuard (https://github.com/cosai-oasis/project-codeguard)
category	secure_development
subcategory	web-security

Client-Side Web Security

Protect browser clients against code injection, request forgery, UI redress, cross-site leaks, and unsafe third-party scripts with layered, context-aware controls.

XSS Prevention (Context-Aware)

• HTML context: prefer textContent. If HTML is required, sanitize with a vetted library (e.g., DOMPurify) and strict allow-lists.
• Attribute context: always quote attributes and encode values.
• JavaScript context: do not build JS from untrusted strings; avoid inline event handlers; use addEventListener.
• URL context: validate protocol/domain and encode; block javascript: and data URLs where inappropriate.
• Redirects/forwards: never use user input directly for destinations; use server-side mapping (ID to URL) or validate against trusted domain allow-lists.
• CSS context: allow-list values; never inject raw style text from users.

Example sanitization:

const clean = DOMPurify.sanitize(userHtml, {
  ALLOWED_TAGS: ['b','i','p','a','ul','li'],
  ALLOWED_ATTR: ['href','target','rel'],
  ALLOW_DATA_ATTR: false
});

DOM-based XSS and Dangerous Sinks

• Prohibit innerHTML, outerHTML, document.write with untrusted data.
• Prohibit eval, new Function, string-based setTimeout/setInterval.
• Validate and encode data before assigning to location or event handler properties.
• Use strict mode and explicit variable declarations to prevent global namespace pollution from DOM clobbering.
• Adopt Trusted Types and enforce strict CSP to prevent DOM sink exploitation.

Trusted Types + CSP:

Content-Security-Policy: script-src 'self' 'nonce-{random}'; object-src 'none'; base-uri 'self'; require-trusted-types-for 'script'

Content Security Policy (CSP)

• Prefer nonce-based or hash-based CSP over domain allow-lists.
• Start with Report-Only mode; collect violations; then enforce.
• Baseline to aim for: default-src 'self'; style-src 'self' 'unsafe-inline'; frame-ancestors 'self'; form-action 'self'; object-src 'none'; base-uri 'none'; upgrade-insecure-requests.

CSRF Defense

• Fix XSS first; then layer CSRF defenses.
• Use framework-native CSRF protections and synchronizer tokens on all state-changing requests.
• Cookie settings: SameSite=Lax or Strict; sessions Secure and HttpOnly; use __Host- prefix when possible.
• Validate Origin/Referer; require custom headers for API mutations in SPA token models.
• Never use GET for state changes; validate tokens on POST/PUT/DELETE/PATCH only. Enforce HTTPS for all token transmission.

Clickjacking Defense

• Primary: Content-Security-Policy: frame-ancestors 'none' or a specific allow-list.
• Fallback for legacy browsers: X-Frame-Options: DENY or SAMEORIGIN.
• Consider UX confirmations for sensitive actions when framing is required.

Cross-Site Leaks (XS-Leaks) Controls

• Set SameSite=Strict cookies for sensitive actions and SameSite=Lax as the default for all other cookies.
• Adopt Fetch Metadata protections to block suspicious cross-site requests.
• Isolate browsing contexts: COOP/COEP and CORP where applicable.
• Disable caching and add user-unique tokens for sensitive responses to prevent cache probing.

Third-Party JavaScript

• Minimize and isolate: prefer sandboxed iframes with sandbox and postMessage origin checks.
• Use Subresource Integrity (SRI) for external scripts and monitor for changes.
• Provide a first-party, sanitized data layer; deny direct DOM access from tags unless a specific integration requires it.
• Govern via tag manager controls and vendor contracts; keep libraries updated.

SRI example:

<script src="https://cdn.vendor.com/app.js"
  integrity="sha384-..." crossorigin="anonymous"></script>

HTML5, CORS, WebSockets, Storage

• postMessage: always specify exact target origin; verify event.origin on receive.
• CORS: avoid *; allow-list origins; validate preflights; do not rely on CORS for authorization.
• WebSockets: require wss://, origin checks, auth, message size limits, and safe JSON parsing.
• Client storage: never store secrets in localStorage/sessionStorage; prefer HttpOnly cookies; if unavoidable, isolate via Web Workers.
• Links: add rel="noopener noreferrer" to external target=_blank links.

HTTP Security Headers

• HSTS: enforce HTTPS everywhere.
• X-Content-Type-Options: nosniff.
• Referrer-Policy and Permissions-Policy: restrict sensitive signals and capabilities.

AJAX and Safe DOM APIs

• Avoid dynamic code execution; use function callbacks, not strings.
• Build JSON with JSON.stringify; never via string concatenation.
• Prefer creating elements and setting textContent/safe attributes over raw HTML insertion.

Implementation Checklist

• Contextual encoding/sanitization for every sink; no dangerous APIs without guards
• Strict CSP with nonces and Trusted Types; violations monitored
• CSRF tokens on all state-changing requests; secure cookie attributes
• Frame protections set; XS-Leak mitigations enabled (Fetch Metadata, COOP/COEP/CORP)
• Third-party JS isolated with SRI and sandbox; vetted data layer only
• HTML5/CORS/WebSocket usage hardened; no secrets in web storage
• Security headers enabled and validated

Test Plan

• Automated checks for dangerous DOM/API patterns.
• E2E tests for CSRF and clickjacking; CSP report monitoring.
• Manual probes for XS-Leaks (frame count, timing, cache) and open redirect behavior.