| name | security-baseline |
| description | Establish a security baseline for a website or web app. Use this skill when configuring HTTPS and TLS, setting security headers, planning secrets management, evaluating CSP policies, doing a basic security audit, or hardening a site before launch. Triggers on security headers, HTTPS, TLS, CSP, content security policy, HSTS, secrets management, vulnerability scan, security audit, harden, OWASP, security baseline. Also triggers when a security review is required for compliance or before going live. |
| category | operations |
| catalog_summary | HTTPS, security headers, CSP, secrets management, vulnerability scans |
| display_order | 7 |
Security Baseline
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.
When to use
- Pre-launch security review
- Setting up a new site or environment
- Periodic security audit (quarterly recommended)
- Onboarding a new vendor or third-party integration
- Responding to a security finding or report
- Hardening after an incident
When NOT to use
- Active incident response (use
incident-response)
- Code-level security review (use
code-review-web)
- Email-specific authentication (SPF/DKIM/DMARC) (use
email-deliverability)
- DNS-level security (CAA, DNSSEC) (use
domain-strategy)
- Performance-related security (DDoS protection sizing) (use
performance-optimization)
Required inputs
- The site or app in scope (URLs, environments)
- The hosting platform and CDN
- Authentication method (if any)
- Third-party scripts and integrations
- Compliance context (PCI, SOC2, GDPR, etc., if applicable)
- Existing security tooling
The framework: 6 layers
Security is layered. Each layer addresses a different attack surface.
Layer 1: Transport security
How data moves from server to client.
- HTTPS everywhere. No HTTP variants serving content.
- TLS 1.2 minimum, TLS 1.3 preferred. Disable TLS 1.0 and 1.1.
- HSTS (Strict-Transport-Security) header set, with
includeSubDomains and preload for high-confidence sites.
- Strong cipher suites only. Modern browsers handle this if you pick a modern config from your provider.
- Certificates from a trusted CA, monitored for expiration.
Layer 2: Response headers
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.
Layer 3: Authentication and authorization
How users prove who they are and what they can do.
- Strong password requirements (length over complexity rules; allow long passphrases)
- Account lockout or rate limiting on login
- 2FA available, required for admin accounts
- Session tokens: short-lived, secure, HttpOnly cookies
- Logout invalidates tokens server-side, not just client-side
- Password reset flows that don't reveal account existence
- Authorization checked on every request (don't rely on UI hiding)
Layer 4: Input handling
How untrusted input is processed.
- Validate on the server (client validation is UX, not security)
- Parameterized queries for any database access (no string concatenation into SQL)
- Output encoding by context (HTML, JS, URL, CSS)
- File upload restrictions (type, size, location, scanning)
- Rate limiting on endpoints that could be abused
- CSRF tokens on state-changing requests
Layer 5: Secrets management
Where credentials and keys live.
- No secrets in code, config files in repos, or environment variables baked into images
- Secrets in a dedicated secrets manager
- Different secrets per environment (no shared dev/prod secrets)
- Rotation schedule documented and followed
- Audit log of secret access
- Limited blast radius (each service has its own credentials, scoped narrowly)
Layer 6: Operational security
How the team operates.
- Access controls reviewed quarterly (offboard immediately on departure)
- 2FA enforced on every admin account (hosting, DNS, registrar, code host, deploy tools)
- Audit logs enabled and reviewed
- Vulnerability scanning (dependencies, containers, infrastructure)
- Patch cadence defined
- Incident response runbook exists (see
incident-response)
- Backups exist and are tested (see
backup-and-disaster-recovery)
- Security contact published (security.txt at /.well-known/security.txt)
Content Security Policy
CSP is the most powerful response header and the most often misconfigured. Worth its own treatment.
What CSP does
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.
Two flavors
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.
Roll out CSP gradually
- Start with
Content-Security-Policy-Report-Only to log violations without blocking.
- Set up a violation report endpoint.
- Watch for legitimate violations (third-party scripts, inline handlers).
- Tune the policy.
- Switch to enforcing mode once violations are mostly false positives.
- Continue monitoring violation reports for new issues.
Common CSP mistakes
unsafe-inline in script-src. Defeats most of CSP's value.unsafe-eval in script-src. Often required by older libraries; refactor or replace.- Wildcard sources (
*). Defeats the policy.
- Allowing CDNs that host arbitrary user content. Attackers can upload scripts to the CDN.
- Not restricting
frame-ancestors. Use this for clickjacking defense (more flexible than X-Frame-Options).
Workflow
Step 1: Run a baseline scan
Use a free scanner: securityheaders.com, or the MDN HTTP Observatory at developer.mozilla.org/en-US/observatory. Get a current grade. This is the floor. If no scan result can be obtained, state the gap per the data-availability rule.
Step 2: Inventory the surface
- Domains and subdomains in scope
- Public endpoints (forms, APIs)
- Authentication entry points
- Admin interfaces
- Third-party integrations and their permissions
Step 3: Audit each layer
Walk the 6 layers. For each, document:
- What's in place
- What's missing
- Risk level (high, medium, low)
Step 4: Prioritize
High risk, easy fixes go first:
- HSTS not set
- Default headers missing
- Admin without 2FA
- Old TLS versions enabled
Medium risk, medium fixes next:
- CSP rollout
- Input validation gaps
- Secret management improvements
Low risk, nice-to-haves last:
- Permissions-Policy refinements
- Optional headers (Cross-Origin-* family)
Step 5: Implement and verify
For each fix:
- Make the change
- Test in a non-production environment
- Verify with a scanner
- Roll out
- Re-verify in production
Step 6: Set up monitoring
- Certificate expiration alerts
- CSP violation reporting
- Failed login monitoring
- Unusual admin activity alerts
- Dependency vulnerability alerts (Dependabot, Snyk, or equivalent)
Step 7: Document the baseline
Write a security baseline document. It says what's expected on every site:
- Required headers
- Required configurations
- Required practices
New sites get audited against this. Existing sites get re-audited periodically.
Step 8: Schedule review
Quarterly is the floor. Add reviews after major changes or incidents.
Common compliance touchpoints
Not legal advice. Surfaces where security baseline meets compliance requirements:
- PCI DSS (if handling payment cards): much more involved than baseline. The baseline is a starting point, not sufficient.
- SOC 2: baseline aligns with most CC controls (CC6 series). Documented baseline plus evidence of execution is the audit ask.
- GDPR / privacy regs: baseline supports security obligations (Article 32). Privacy is broader than security.
- HIPAA, HITRUST, FedRAMP: baseline is necessary, far from sufficient. Get specialized help.
When compliance applies, the baseline is necessary but not the full answer.
Failure patterns
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 months to reach users through a Chrome update, with no guarantee for other browsers. 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.
Output format
A security baseline document includes:
- Inventory: what's in scope
- Layer-by-layer status: what's in place, what's missing
- Required headers: with values, applied per environment
- Required configurations: TLS, secrets, auth
- Required operational practices: access reviews, patch cadence, audit logging
- Findings: prioritized list of gaps
- Remediation plan: owners, dates
- Re-audit cadence: when this is reviewed next
If required data is unavailable
This skill's output depends on data, measurements, or tool results it cannot generate on its own. When a required input, tool, or data source is unavailable or unverifiable, the sanctioned output is the deliverable with the gap stated: what was needed, what was actually obtained or verified, and which parts of the output are affected. Fabricating, estimating, or interpolating a required number to complete the deliverable is never sanctioned. A stated gap is a complete answer.
Reference files
