Jump to

Skill · Security baseline

Security baseline.

Establish the security floor every production site needs before launch.

Establish the security floor for any production website or app: the things that should be in place before public launch and verified periodically after. Security is layered, and the skill walks six of them, each addressing a different attack surface, from transport security up through operational practice.

It prioritizes the easy high-impact wins (the free default headers, 2FA on every admin account) and treats Content Security Policy as the header worth its own attention. The baseline is necessary for compliance, never the whole answer.

Audience: engineers and ops teams hardening a site before launch, running a periodic security audit, or onboarding a new third-party integration.

View the skill on GitHubBrowse the full catalog

The framework

Six layers, each a different attack surface.

Security is layered. Each layer addresses a surface the others do not.

  1. 01Transport security: HTTPS everywhere, TLS 1.2 minimum with 1.3 preferred, HSTS, strong cipher suites, and certificates from a trusted CA monitored for expiration.
  2. 02Response headers: HSTS, Content Security Policy, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy, and the Cross-Origin family.
  3. 03Authentication and authorization: long passphrases over complexity rules, login rate limiting, 2FA required for admins, short-lived secure HttpOnly session tokens, and authorization checked on every request.
  4. 04Input handling: server-side validation, parameterized queries, context-aware output encoding, file-upload restrictions, endpoint rate limiting, and CSRF tokens on state-changing requests.
  5. 05Secrets management: nothing in code or baked into images, a dedicated secrets manager, different secrets per environment, a documented rotation schedule, and a narrow blast radius.
  6. 06Operational security: quarterly access reviews, 2FA on every admin account, audit logs, vulnerability scanning, a patch cadence, an incident runbook, tested backups, and a published security.txt.

What the browser is told

The headers to set, and why.

Most of these are free to set and easy to verify with a scanner. The defaults below are the starting point; CSP is site-specific and deserves the most care.

  1. 01

    Strict-Transport-Security

    Forces HTTPS. Set max-age and includeSubDomains; add preload only once HTTPS is solid across every subdomain, since removing a preload takes weeks.

  2. 02

    Content-Security-Policy

    Restricts which sources can load. The most powerful header and the most often misconfigured; prefer a strict, nonce-based policy over an allowlist.

  3. 03

    X-Content-Type-Options

    Set to nosniff to prevent MIME-type sniffing. Free and easy; one of the defaults that is too often missing.

  4. 04

    X-Frame-Options

    DENY or SAMEORIGIN for clickjacking protection, with CSP frame-ancestors as the more flexible modern equivalent.

  5. 05

    Referrer-Policy

    strict-origin-when-cross-origin controls how much referrer information leaks to other sites.

  6. 06

    Permissions-Policy

    Controls browser features such as camera and microphone, configured per site.

  7. 07

    Cross-Origin family

    Cross-Origin-Opener-Policy and Cross-Origin-Embedder-Policy add process isolation where compatible.

Reference files

The reference that goes alongside the SKILL.md.

  • references/headers-checklist.md

    A copy-paste checklist of recommended security headers with example values, organized by tier of importance.

Browse all reference files on GitHub

Bridges to other skills

The neighbors of the baseline.

The baseline is the floor. These cover the security concerns that sit just outside it and the response when something gets through.

  • Code-level security

    code-review-web

    Code-level security review (injection paths, auth logic, unsafe patterns) happens in the review. The baseline covers configuration; the review covers the code.

  • When it gets through

    incident-response

    When a baseline is breached or an active incident is underway, response takes over. The baseline lowers the odds; incident response handles the event.

  • Email authentication

    email-deliverability

    SPF, DKIM, and DMARC are email-specific authentication that the baseline points at rather than owns. That skill sets them up.

  • DNS-level security

    domain-strategy

    CAA records and DNSSEC are DNS-level protections. The baseline secures the site; domain strategy secures the records that resolve it.

  • DDoS sizing

    performance-optimization

    Sizing DDoS protection and capacity is a performance and infrastructure concern, distinct from the security configuration the baseline establishes.

Open source under MIT

Read the SKILL.md on GitHub.

The skill source lives in the rampstackco/claude-skills repository alongside dozens of other skills covering the full lifecycle of brand and product work. This page is a structured overview; the SKILL.md is the source. MIT licensed.

View SKILL.mdBrowse the full catalog

Frequently asked questions.

What are the six security layers?
Transport security (HTTPS, TLS, HSTS), response headers (what the browser is told about the site), authentication and authorization (how users prove identity and what they may do), input handling (how untrusted input is processed), secrets management (where credentials live), and operational security (how the team operates). Each layer addresses a different attack surface, so the audit walks all six and documents what is in place, what is missing, and the risk level for each.
What is the easiest high-impact security win?
Two things. Set the default response headers (X-Content-Type-Options as nosniff, X-Frame-Options, and Referrer-Policy are free and easy), and enforce 2FA on every admin account across hosting, DNS, registrar, code host, and deploy tools. Admin without 2FA is the single most common high-impact vulnerability across small teams. Both are fast, and both close gaps that attackers reach for first.
How should I roll out a Content Security Policy?
Gradually, and prefer a strict (nonce-based) policy over a legacy allowlist. Start with Content-Security-Policy-Report-Only to log violations without blocking, set up a violation report endpoint, watch for legitimate violations from third-party scripts and inline handlers, tune the policy, then switch to enforcing mode once violations are mostly false positives, and keep monitoring. Avoid unsafe-inline and wildcard sources, which defeat most of CSP's value, and use frame-ancestors for clickjacking defense.
Where should secrets live?
In a dedicated secrets manager, never in code, in config files committed to repos, or in environment variables baked into images, because anyone with image access then has the secrets. Use different secrets per environment so a dev leak does not expose production, document and follow a rotation schedule, scope each service's credentials narrowly to limit blast radius, and keep an audit log of secret access.
Is a baseline enough for compliance?
No. The baseline is necessary but not sufficient. It aligns with most of SOC 2's CC6 controls and supports GDPR's Article 32 security obligations, but PCI DSS (for payment cards), HIPAA, HITRUST, and FedRAMP all need far more than a baseline. Treat it as a starting point where regulations apply and get specialized help, because a documented baseline plus evidence of execution is only the beginning of what those frameworks ask for.