Stats
Actions
Tags
From rampstack-skills
Establishes a security baseline for websites and web apps covering HTTPS, TLS, security headers, CSP, secrets management, and vulnerability scans. Use before launch or for periodic audits.
How this skill is triggered — by the user, by Claude, or both
Slash command
/rampstack-skills:security-baselineThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Establish the security floor for any production website or web app. Stack-agnostic. Covers the things that should be in place before public launch and verified periodically after.
Establish the security floor for any production website or web app. Stack-agnostic. Covers the things that should be in place before public launch and verified periodically after.
incident-response)code-review-web)email-deliverability)domain-strategy)performance-optimization)Security is layered. Each layer addresses a different attack surface.
How data moves from server to client.
includeSubDomains and preload for high-confidence sites.What the browser is told about your site.
| Header | Purpose | Default value |
|---|---|---|
Strict-Transport-Security | Force HTTPS | max-age=31536000; includeSubDomains |
Content-Security-Policy | Restrict resource loading | Site-specific |
X-Content-Type-Options | Prevent MIME sniffing | nosniff |
X-Frame-Options | Clickjacking protection | DENY or SAMEORIGIN |
Referrer-Policy | Control referrer info | strict-origin-when-cross-origin |
Permissions-Policy | Control browser features | Site-specific (camera, mic, etc.) |
Cross-Origin-Opener-Policy | Process isolation | same-origin (where compatible) |
Cross-Origin-Embedder-Policy | Cross-origin restrictions | require-corp (where applicable) |
CSP deserves its own attention. See the framework section below.
How users prove who they are and what they can do.
How untrusted input is processed.
Where credentials and keys live.
How the team operates.
incident-response)backup-and-disaster-recovery)CSP is the most powerful response header and the most often misconfigured. Worth its own treatment.
CSP tells the browser which sources are allowed for various resource types: scripts, styles, images, frames, connections, etc. A strict CSP prevents most XSS attacks even when input handling has bugs.
Strict CSP (recommended): uses nonce- or hash- based source allowlists. Inline scripts must be explicitly allowed via nonce.
Content-Security-Policy: script-src 'self' 'nonce-{random}' 'strict-dynamic'; object-src 'none'; base-uri 'self';
Allowlist CSP (legacy): lists allowed domains. Easier to set up, much weaker.
Content-Security-Policy: script-src 'self' https://trusted.com; ...
Strict CSP requires application changes (every inline script needs a nonce). The investment pays off.
Content-Security-Policy-Report-Only to log violations without blocking.unsafe-inline in script-src. Defeats most of CSP's value.unsafe-eval in script-src. Often required by older libraries; refactor or replace.*). Defeats the policy.frame-ancestors. Use this for clickjacking defense (more flexible than X-Frame-Options).Use a free scanner: securityheaders.com, observatory.mozilla.org. Get a current grade. This is the floor.
Walk the 6 layers. For each, document:
High risk, easy fixes go first:
Medium risk, medium fixes next:
Low risk, nice-to-haves last:
For each fix:
Write a security baseline document. It says what's expected on every site:
New sites get audited against this. Existing sites get re-audited periodically.
Quarterly is the floor. Add reviews after major changes or incidents.
Not legal advice. Surfaces where security baseline meets compliance requirements:
When compliance applies, the baseline is necessary but not the full answer.
HSTS without includeSubDomains. Attacker tricks browser into HTTP on a subdomain you haven't HTTPS'd yet.
HSTS preload without commitment. Once preloaded, removing it takes weeks. Don't preload until HTTPS is solid across all subdomains forever.
CSP with unsafe-inline. Defeats most of CSP. Either go strict (nonce-based) or accept that CSP is providing limited protection.
Default headers missing. X-Content-Type-Options, X-Frame-Options, Referrer-Policy are easy and free. Set them.
Admin without 2FA. The single most common high-impact vulnerability across small teams. Fix today.
Secrets in environment variables baked into images. Anyone with image access has the secrets. Use a runtime secret manager.
No security.txt. Researchers find issues; they need somewhere to report. Publish a security.txt at /.well-known/security.txt.
Old TLS versions enabled. Disable TLS 1.0 and 1.1. Most providers offer this as a checkbox.
CDN allowing arbitrary inline scripts via misconfigured CSP. The CDN proxies user content; attackers leverage that. Audit the CSP against actual loaded resources.
No incident response plan. When (not if) something happens, no runbook = chaos. See incident-response.
Vulnerability scanning without remediation. Reports pile up. The scan is theater unless someone fixes findings.
Penetration test ignored. Pen test report sits on a shelf. Test results without remediation are worse than no test.
A security baseline document includes:
references/headers-checklist.md: A copy-paste checklist of recommended security headers with example values, organized by tier of importance.npx claudepluginhub rampstackco/claude-skills --plugin rampstack-skillsAudits HTTP security headers (CSP, HSTS, X-Frame-Options, Permissions-Policy), identifies overly permissive directives, and generates production-ready policies for web applications.
Validates HTTP security headers in web app responses, identifies issues like missing CSP or HSTS, rates posture, checks OWASP compliance, and suggests fixes for XSS, clickjacking, and MIME sniffing.
Produce a hardening spec and implement it — auth patterns, security headers, rate limiting, input validation, secrets management, dependency hygiene. Use when asked to "harden this", "add security to this service", "what security do I need", or "secure this before launch".