| 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
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.
