Stats
Actions
Tags
From godmode
Use when writing code that processes user input, manages authentication or authorization, constructs database queries, handles file operations, interacts with external data, exposes API endpoints, or manages secrets - any code that crosses a trust boundary
How this skill is triggered — by the user, by Claude, or both
Slash command
/godmode:security-protocolThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Security is not a phase you bolt on. Every line of code is a security decision.
Security is not a phase you bolt on. Every line of code is a security decision.
Core principle: Never trust data from outside your trust boundary. Validate at every boundary crossing.
No exceptions. No workarounds. No shortcuts.
NO EXTERNAL DATA REACHES A SYSTEM CALL, QUERY, OR OUTPUT WITHOUT VALIDATION AND SANITIZATION
When data crosses a trust boundary, it must be validated before consumption. This is absolute.
Mandatory when writing code that:
This is not discretionary. Security awareness is woven into development, not applied afterward.
BEFORE shipping ANY code that handles external data:
1. IDENTIFY: Where does data enter the system? (Trust boundary)
2. VALIDATE: Is input validated at the boundary?
3. SANITIZE: Is output encoded for its target context?
4. AUTHORIZE: Is access control verified before the action?
5. PROTECT: Are secrets, tokens, and keys managed safely?
Omit any step = vulnerability shipped
Every endpoint must verify: Can THIS user perform THIS action on THIS resource?
# VULNERABLE: Checks authentication but not authorization
GET /api/accounts/456/profile # User 123 views user 456's private data
# SECURE: Verify resource ownership
if resource.owner_id != authenticated_user.id:
return 403 Forbidden
| Verification | Method |
|---|---|
| Authentication | Is the user who they claim to be? |
| Authorization | Is this user permitted to perform this action? |
| Resource ownership | Does this user own this specific resource? |
| Role enforcement | Server-side role check; never trust client-provided role claims |
Default posture: deny. If no explicit rule grants access, access is denied.
| Required Practice | Prohibited Practice |
|---|---|
| bcrypt/scrypt/argon2 for password hashing | MD5, SHA1, SHA256 for passwords |
| TLS everywhere (HTTPS) | HTTP for anything sensitive |
| Cryptographically secure RNG for tokens | Math.random() for security tokens |
| Encrypt sensitive data at rest | Store sensitive data in plaintext |
| Use established cryptographic libraries | Implement custom cryptography |
Never concatenate external input into queries, commands, or templates.
| Injection Vector | Prevention |
|---|---|
| SQL injection | Parameterized queries / prepared statements. Always. |
| NoSQL injection | Type-check inputs; use ODM query builders |
| Command injection | Avoid shell execution. If unavoidable: allowlist arguments, never interpolate |
| LDAP injection | Escape special characters; use parameterized queries |
| Template injection | Use auto-escaping template engines |
-- VULNERABLE: String concatenation
SELECT * FROM users WHERE email = '" + userInput + "'
-- SECURE: Parameterized query
SELECT * FROM users WHERE email = $1
This is non-negotiable. There is no scenario where string concatenation in queries is acceptable.
| Checkpoint | Action |
|---|---|
| Default credentials | Replace all defaults before deployment |
| Debug features | Disable debug mode, admin consoles, and verbose errors in production |
| Error verbosity | Never expose stack traces, SQL errors, or internal paths to users |
| Directory listing | Disable on all web servers |
| Security headers | Set them (see Security Headers section) |
| CORS policy | Restrict to specific origins; never * for credentialed requests |
BEFORE adding any dependency:
1. Is it actively maintained? (Last commit within 6 months)
2. Are known vulnerabilities published? (npm audit, snyk, dependabot)
3. Is it widely adopted? (Download counts and stars are signals, not guarantees)
4. Is it actually necessary? (Do not add a dependency for a single utility function)
Execute npm audit / pip audit / cargo audit regularly. Remediate critical and high findings immediately.
| Requirement | Implementation |
|---|---|
| Password storage | bcrypt/scrypt/argon2 with unique salts |
| Session tokens | Cryptographically random, httpOnly, secure, sameSite flags |
| Brute-force protection | Lock account after 5-10 consecutive failures |
| Multi-factor authentication | Support TOTP minimum for sensitive applications |
| Password policy | Minimum 8 characters; cross-reference against breach databases |
| Session lifecycle | Expire sessions; invalidate on password change |
eval(), no pickle.loads() on user input)| Log | Never Log |
|---|---|
| Authentication attempts (success and failure) | Passwords or authentication tokens |
| Authorization denials | Complete credit card numbers |
| Input validation failures | Personally identifiable information without purpose |
| System errors | Encryption keys or secrets |
Set these on every HTTP response:
Content-Security-Policy: default-src 'self'; script-src 'self'
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Strict-Transport-Security: max-age=31536000; includeSubDomains
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()
Begin restrictive and relax only when a specific requirement demands it.
NEVER:
- Embed secrets in source code
- Commit .env files to version control
- Write secrets to log output
- Transmit secrets in URL query parameters
- Store secrets in client-side code
ALWAYS:
- Use environment variables or dedicated secret managers
- Add .env to .gitignore BEFORE the first commit
- Rotate secrets on a defined schedule
- Use distinct secrets per environment
- Audit secret access
For every input field:
| Rationalization | Truth |
|---|---|
| "Internal tool, no attacker" | Internal tools get compromised. Internal users make mistakes. Insider threats are real. |
| "We will add security later" | Security is not a feature. Retrofitting it costs 10x more than building it in. |
| "The framework handles it" | Frameworks have escape hatches. Know exactly what your framework does and does not protect. |
| "Input validation is excessive" | Every injection attack in history started with unvalidated input. |
| "It is just a prototype" | Prototypes become production systems. Secure from the beginning. |
| "Too complicated, slows development" | Data breaches slow development permanently. |
| "Nobody would do that" | Attackers do exactly that. Assume all input is hostile. |
eval() or exec() on user-provided data* CORS policy with credentialsEvery item on this list is a security vulnerability. Remediate before shipping.
Complementary skills:
Trust boundary crossed -> validate input, sanitize output, verify authorization
No exceptions. No "we will add it later." Security ships with the code or the code does not ship.
npx claudepluginhub noobygains/godmode --plugin godmodeEnforces security-conscious coding: trust boundary identification, input validation, injection prevention, secrets management, and defense-in-depth authorization. Activates when handling user input, auth, DB queries, external APIs, file ops, or on security review requests.
Applies proactive security hardening at trust boundaries: input validation, auth, sensitive data, external APIs, file uploads. Includes OWASP Top 10 quick reference and a three-tier boundary system.
Enforces security best practices and vulnerability prevention: input validation, authentication, secrets management, OWASP top 10. Activated by security, auth, vulnerability, injection, XSS, CSRF, rate-limit keywords.