AgentStack
Browse Sign in
Browse Why AgentStack Sell Docs
Sign in
SKILL verified Apache-2.0 Self-run

Client Side Security

skill-redhatproductsecurity-prodsec-skills-client-side-security · by RedHatProductSecurity

>

No reviews yet
0 installs
36 views
0.0% view→install

Install

$ agentstack add skill-redhatproductsecurity-prodsec-skills-client-side-security

✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.

Security review

✓ Passed

No issues found. Passed automated security review. · v0.1.0 How review works →

  • Prompt-injection patterns
  • Secret / credential exfiltration
  • Dangerous shell & filesystem operations
  • Untrusted network calls
  • Known-malicious package signatures

What it can access

  • Network access Used
  • Filesystem access No
  • Shell / process execution No
  • Environment & secrets No
  • Dynamic code execution No

From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.

View the full security report →

Verified badge

Passed review? Show it. Paste this badge into your README, it links to the public security report.

AgentStack Verified badge Links to your public security report.
[![AgentStack Verified](https://agentstack.voostack.com/badges/verified.svg)](https://agentstack.voostack.com/security/report/skill-redhatproductsecurity-prodsec-skills-client-side-security)

Reliability & compatibility

Security review passed
0 installs to date
no reviews yet
2mo ago

Declared compatibility

Claude CodeClaude Desktop

Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.

Preview Execution monitoring

We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.

How agent discovery & health will work →
Are you the author of Client Side Security? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

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:

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.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet, be the first.

Versions

  • v0.1.0 Imported from the upstream source.