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
npx claudepluginhub noobygains/godmode --plugin godmodeThis skill uses the workspace's default tool permissions.
Security is not a phase you bolt on. Every line of code is a security decision.
Hardens web app code against OWASP Top 10 vulnerabilities like injection and broken authentication. Use when handling user input, auth, sessions, data storage, or external integrations.
Provides OWASP Top 10 guidance and stack-agnostic principles for secure web apps. Use for code security reviews, auth/authorization implementation, secrets/API key handling, security headers, injection prevention (SQL/XSS/CSRF), and audits.
Mandates invoking relevant skills via tools before any response in coding sessions. Covers access, priorities, and adaptations for Claude Code, Copilot CLI, Gemini CLI.
Share bugs, ideas, or general feedback.
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.