# Florianbuetow Claude Code Harden > Security Hardening - Skill: `tomevault-io/florianbuetow-claude-code-harden` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add tomevault-io/florianbuetow-claude-code-harden` - Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/florianbuetow-claude-code-harden/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Security - Author: tomevault-io (https://skillmd.com/u/tomevault-io) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tomevault-io/florianbuetow-claude-code-harden --- # Security Hardening Proactive security improvement suggestions. Unlike vulnerability scanners that find what is broken, this skill identifies what could be better -- defense-in-depth measures, missing security headers, insufficient input validation, absent rate limiting, and other hardening opportunities that reduce the blast radius of future vulnerabilities. ## Supported Flags Read `../../shared/schemas/flags.md` for the full flag specification. | Flag | Hardening Behavior | |------|-------------------| | `--scope` | Default `changed`. Use `full` for comprehensive hardening review. | | `--depth quick` | Check for missing security headers and obvious hardening gaps only. | | `--depth standard` | Full hardening review: headers, validation, logging, error handling, configuration. | | `--depth deep` | Standard + analyze middleware chains, review all trust boundaries, check defense layering. | | `--depth expert` | Deep + compare against security benchmarks (CIS, OWASP ASVS), generate hardening scorecard. | | `--severity` | Filter suggestions by impact level. | | `--format` | Default `text`. Use `md` for a hardening checklist document. | ## Workflow ### Step 1: Identify Technology Stack Scan the codebase to determine: 1. **Web framework(s)**: Express, Django, Flask, Spring, Rails, Next.js, ASP.NET, FastAPI, etc. 2. **Deployment target**: Container, serverless, VM, PaaS (from Dockerfile, serverless.yml, etc.). 3. **Reverse proxy/CDN**: Nginx, Apache, Cloudflare, AWS ALB (from config files). 4. **Database(s)**: SQL, NoSQL, cache layers. 5. **Authentication mechanism**: Session, JWT, OAuth, SAML. 6. **Existing security middleware**: Helmet, django-security, Spring Security, etc. ### Step 2: Check Security Headers Verify the application sets these HTTP response headers (or that a reverse proxy / CDN handles them): | Header | Recommended Value | Impact | |--------|------------------|--------| | `Content-Security-Policy` | Strict policy, no `unsafe-inline` / `unsafe-eval` | Mitigates XSS | | `Strict-Transport-Security` | `max-age=31536000; includeSubDomains; preload` | Enforces HTTPS | | `X-Content-Type-Options` | `nosniff` | Prevents MIME sniffing | | `X-Frame-Options` | `DENY` or `SAMEORIGIN` | Prevents clickjacking | | `Referrer-Policy` | `strict-origin-when-cross-origin` or stricter | Limits referrer leakage | | `Permissions-Policy` | Disable unused browser features | Reduces attack surface | | `Cross-Origin-Opener-Policy` | `same-origin` | Prevents cross-origin attacks | | `Cross-Origin-Resource-Policy` | `same-origin` | Controls resource sharing | | `Cache-Control` | `no-store` for sensitive responses | Prevents cache leaks | Note: If a reverse proxy config (nginx.conf, etc.) is present and sets these headers, do not flag them as missing from application code. ### Step 3: Review CORS Configuration Check for overly permissive CORS settings: 1. `Access-Control-Allow-Origin: *` on authenticated endpoints. 2. Reflecting the `Origin` header without validation. 3. `Access-Control-Allow-Credentials: true` with wildcard origins. 4. Overly broad allowed methods or headers. 5. Missing `Vary: Origin` when origin is dynamic. ### Step 4: Assess Input Validation For each entry point discovered (or in scope): 1. **Schema validation**: Are request bodies validated against a schema (Joi, Zod, Pydantic, JSON Schema)? 2. **Type coercion**: Are string inputs properly typed before use? 3. **Length limits**: Are string lengths bounded? Are array sizes limited? 4. **Allowlist vs denylist**: Is validation positive (allowlist) rather than negative (denylist)? 5. **Nested input**: Are deeply nested objects limited to prevent DoS? 6. **File validation**: Are uploaded files validated beyond extension (magic bytes, size limits)? ### Step 5: Check Rate Limiting Identify endpoints that should have rate limiting: 1. **Authentication endpoints**: Login, registration, password reset, MFA verification. 2. **API endpoints**: Especially those that are computationally expensive or return sensitive data. 3. **File upload endpoints**: To prevent storage exhaustion. 4. **Search/query endpoints**: To prevent enumeration and DoS. Check if rate limiting is implemented and whether limits are reasonable. ### Step 6: Review Error Handling and Information Disclosure 1. **Stack traces**: Are stack traces exposed in production error responses? 2. **Verbose errors**: Do error messages reveal internal paths, versions, or database details? 3. **Error differentiation**: Do auth errors distinguish between "user not found" and "wrong password" (enables enumeration)? 4. **Default error pages**: Are framework default error pages replaced? 5. **Debug mode**: Is debug mode disabled in production configuration? ### Step 7: Assess Security Logging Check that these security-relevant events are logged: 1. **Authentication events**: Login success/failure, logout, password changes. 2. **Authorization failures**: Access denied events with user and resource context. 3. **Input validation failures**: Rejected requests with sanitized details. 4. **Administrative actions**: Config changes, user management, privilege changes. 5. **Sensitive data access**: Audit trail for PII/financial data reads. Verify logs do NOT contain: passwords, tokens, credit card numbers, SSNs, or other sensitive data. ### Step 8: Check Defensive Coding Patterns 1. **Fail-closed defaults**: Do authorization checks default to deny? 2. **Secure defaults**: Are new configurations secure by default? 3. **Least privilege**: Do database connections, API keys, and service accounts use minimal permissions? 4. **Timeout configuration**: Do HTTP clients, database connections, and external calls have timeouts? 5. **Resource limits**: Are memory/CPU-intensive operations bounded? 6. **Dependency security**: Is `npm audit` / `pip audit` / equivalent run in CI? ### Step 9: Report Output hardening suggestions grouped by category. ## Output Format Hardening suggestions are advisory and use a lighter format than vulnerability findings. ``` ## Security Hardening Report ### Summary - Hardening suggestions: N - By priority: N HIGH, N MEDIUM, N LOW - Categories covered: headers, cors, validation, rate-limiting, logging, error-handling, config ### HIGH Priority #### [H-001] Missing Content-Security-Policy header **Category**: Headers | **Effort**: Low **Location**: src/middleware/security.ts **Current**: No CSP header set **Recommended**: Add strict CSP via helmet ```js app.use(helmet.contentSecurityPolicy({ directives: { defaultSrc: ["'self'"], scriptSrc: ["'self'"], styleSrc: ["'self'", "'unsafe-inline'"], imgSrc: ["'self'", "data:"], } })); ``` ### MEDIUM Priority ... ### LOW Priority ... ``` When hardening gaps represent actual vulnerabilities (e.g., CORS misconfiguration allowing credential theft), emit a formal finding using `../../shared/schemas/findings.md`. Finding ID prefix: **HARD** (e.g., `HARD-001`). - `metadata.tool`: `"harden"` - `references.cwe`: Varies by suggestion (e.g., `CWE-693` Protection Mechanism Failure, `CWE-16` Configuration) ## Pragmatism Notes - Hardening is contextual. An internal admin tool has different requirements than a public API. - Do not recommend CSP for a CLI tool or rate limiting for a batch job. - If a CDN or reverse proxy handles headers, note that rather than flagging missing headers in app code. - Prioritize suggestions that are easy to implement with high security impact. - Acknowledge when existing security measures are already good. Not every review needs findings. - Some frameworks (Next.js, Rails) include secure defaults. Credit what is already done well. --- > Converted and distributed by [TomeVault](https://tomevault.io/claim/florianbuetow) — claim your Tome and manage your conversions.