/security-hardening

name: security-hardening
description: Applies OWASP Top 10, secrets management, and least-privilege principles before any code ships. Security is a build step, not an afterthought.
category: harden
applies-to: [claude, gemini, cursor, copilot, any]
version: 1.0.0

Overview

Security vulnerabilities are almost always cheaper to prevent than to remediate. This skill embeds security review as a required gate in the development workflow — not a separate audit that happens later (and often never).

When to Use

• Before any code involving user input
• Before any code touching authentication, authorization, or sessions
• Before any API endpoint is created or modified
• Before any code that handles secrets, credentials, or PII
• Before any code that makes outbound network requests

Process

Step 1: Threat Model the Change

1. Ask: *Who are the attackers? What are they trying to achieve?* 2. Identify all trust boundaries in the code:

• Where does user-controlled data enter the system?
• Where does that data flow?
• Where is it stored or transmitted?

3. For each trust boundary, name the top 3 attack vectors.

**Verify:** You can name at least one realistic attack scenario for this code.

Step 2: Apply OWASP Top 10 Checklist

4. For each applicable item, confirm it is addressed:

| OWASP Item | Check | |------------|-------| | **A01 Broken Access Control** | Authorization checked at every endpoint? Principle of least privilege applied? | | **A02 Cryptographic Failures** | No plaintext PII/secrets? Using modern algorithms (AES-256, SHA-256+)? TLS everywhere? | | **A03 Injection** | All user input parameterized/sanitized? No raw SQL/shell construction? | | **A04 Insecure Design** | Threat model done? Secure defaults? Fail closed (not open)? | | **A05 Security Misconfiguration** | No default credentials? Unnecessary features disabled? Error messages don't leak internals? | | **A06 Vulnerable Components** | Dependencies up to date? Known CVEs checked? | | **A07 Auth Failures** | Brute-force protection? Session management correct? MFA available? | | **A08 Software Integrity** | Dependencies verified? Supply chain integrity? | | **A09 Logging Failures** | Security events logged? No secrets in logs? Logs protected from tampering? | | **A10 SSRF** | Outbound requests validated? Internal IPs blocked from user-controlled URLs? |

**Verify:** Each applicable item is either addressed or explicitly accepted as a known risk.

Step 3: Secrets Management

5. **No hardcoded secrets** — ever. Not even in dev/test code. 6. Secrets are stored in: environment variables, secrets manager (Vault, AWS Secrets Manager, etc.), or encrypted config. 7. Secrets are **never** logged, printed, or included in error messages. 8. Secrets are **never** committed to git (check `.gitignore` and use pre-commit hooks).

**Verify:** `git grep -i 'password\|secret\|key\|token'` returns no hardcoded values in code.

Step 4: Input Validation

9. Every piece of external input is validated:

• Type check
• Length/size limits
• Allowlist of expected values (not blocklist)
• Reject and log unexpected input — never silently ignore

10. User-controlled data is **never** concatenated into SQL, shell commands, HTML, or file paths without proper escaping/parameterization.

**Verify:** All external input has explicit validation with reject-by-default behavior.

Step 5: Least Privilege

11. Database connections use the minimum required permissions. 12. API tokens have the minimum required scopes. 13. Service accounts cannot access resources they don't need. 14. Default deny — access must be explicitly granted, not implicitly inherited.

**Verify:** List every permission granted by this code. Is each one required?

Common Rationalizations (and Rebuttals)

| Excuse | Rebuttal | |--------|----------| | "It's internal only" | Internal services get breached too. Zero-trust applies internally. | | "We'll add auth later" | Auth bolted on later is always broken. Design it in from the start. | | "The input is from our own frontend" | Attackers don't use your frontend. Validate on the server, always. | | "It's a dev environment" | Dev environments get credentials from prod. Treat them accordingly. | | "The secret is in a config file, not code" | Is the config file in git? Is it world-readable? Config files are not safe. |

Red Flags

• User input directly interpolated into queries or commands
• Authentication middleware that can be bypassed
• Error messages that include stack traces or SQL queries
• API keys or passwords in source code or comments
• Missing authorization check on any endpoint
• HTTP used instead of HTTPS for any sensitive data

Verification

• [ ] OWASP Top 10 checklist reviewed for applicable items
• [ ] No hardcoded secrets (`git grep` clean)
• [ ] All external input validated (type, length, allowlist)
• [ ] No raw SQL/shell from user input
• [ ] Least privilege applied to all credentials
• [ ] Security events are logged (but secrets are not)
• [ ] Dependency vulnerabilities checked

References

• [OWASP Top 10](https://owasp.org/www-project-top-ten/)
• [prompt-injection-defense skill](../prompt-injection-defense/SKILL.md)
• [references/security-checklist.md](../../references/security-checklist.md)