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
• prompt-injection-defense skill
• references/security-checklist.md