home / skills / a5c-ai / babysitter / csp

csp skill

safe

/plugins/babysitter/skills/babysit/process/specializations/web-development/skills/csp

This skill helps you implement Content Security Policy hardening, nonces, and reporting across apps to prevent XSS and enforce secure scripting.

npx playbooks add skill a5c-ai/babysitter --skill csp

Review the files below or copy the command above to add this skill to your agents.

Files (2)

SKILL.md

796 B

---
name: csp
description: Content Security Policy configuration, nonces, and reporting.
allowed-tools: Read, Write, Edit, Bash, Glob, Grep
---

# CSP Skill

Expert assistance for Content Security Policy implementation.

## Capabilities

- Configure CSP headers
- Implement nonces
- Set up reporting
- Handle inline scripts
- Configure strict CSP

## CSP Configuration

```typescript
// Next.js middleware
const cspHeader = `
  default-src 'self';
  script-src 'self' 'nonce-${nonce}' 'strict-dynamic';
  style-src 'self' 'nonce-${nonce}';
  img-src 'self' blob: data:;
  font-src 'self';
  connect-src 'self';
  frame-ancestors 'none';
  base-uri 'self';
  form-action 'self';
  report-uri /api/csp-report;
`;
```

## Target Processes

- security-hardening
- csp-implementation
- xss-prevention

Overview

This skill helps implement and maintain Content Security Policy (CSP) for web applications, including header configuration, nonces, and reporting. It provides practical guidance and templates to reduce XSS risk and enable structured violation reporting. The goal is a defendable, developer-friendly CSP that supports modern app patterns like dynamic scripts and inline styles when safe.

How this skill works

The skill inspects application entry points and suggests CSP header values tailored to your runtime (server middleware, static headers, or frameworks like Next.js). It recommends nonce generation and injection patterns for per-request nonces and shows how to wire up a reporting endpoint to collect violation data. It also explains strict directives such as strict-dynamic and frame-ancestors and trade-offs when permitting inline code.

When to use it

When hardening a web app against XSS and script injection.
When moving from permissive CSP to stricter, report-enabled policies.
When introducing server-generated, per-request nonces for inline scripts or styles.
When you need automated collection of CSP violation reports for monitoring.
When configuring CSP for single-page apps with dynamic script loading.

Best practices

Generate a cryptographically secure nonce per HTTP response and inject it into script/style tags and the CSP header.
Start with report-only mode to collect violations before enforcing blocks.
Prefer 'strict-dynamic' with nonces for apps that load trusted scripts dynamically instead of broad host whitelists.
Avoid using unsafe-inline or unsafe-eval; if unavoidable, limit exposure with nonces and additional controls.
Implement a dedicated reporting endpoint that validates and aggregates reports for triage.

Example use cases

Add CSP middleware to a Next.js app that generates nonces and sets a strict header with report-uri for staging.
Convert legacy inline scripts to nonce-based inline execution during a staged hardening rollout.
Enable report-only CSP in production to discover third-party resources that need allowlisting.
Configure frame-ancestors and form-action to mitigate clickjacking and form-targeting attacks.
Integrate CSP violation reports into a security dashboard for long-term monitoring and remediation.

FAQ

Do I need nonces for every request?

Yes — generate a fresh, unpredictable nonce per response so attackers cannot reuse values across requests.

Can I use report-only while transitioning?

Absolutely. Use report-only to collect real-world violations, then iterate on the policy before enforcing it.