Security Protocol

Security Protocol

Overview

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.

The Prime Directive

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.

When to Use

Mandatory when writing code that:

• Accepts user input (forms, URLs, headers, uploaded files)
• Constructs database queries
• Renders user-supplied content
• Manages authentication or authorization
• Handles secrets or credentials
• Invokes external APIs
• Manipulates file paths
• Executes system commands
• Sets HTTP response headers
• Processes file uploads

This is not discretionary. Security awareness is woven into development, not applied afterward.

The Entry Protocol

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

OWASP Top 10 Condensed Guide

A01: Broken Access Control

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.

A02: Cryptographic Failures

| 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 |

A03: Injection

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.

A04: Insecure Design

• Enforce rate limiting on authentication endpoints
• Use CAPTCHA or proof-of-work for account creation
• Validate business logic constraints server-side (never client-side only)
• Design for abuse scenarios, not just intended usage

A05: Security Misconfiguration

| 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 |

A06: Vulnerable Components

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.

A07: Authentication Failures

| 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 |

A08: Data Integrity Failures

• Verify integrity of software updates and CI/CD pipelines
• Use signed artifacts and checksums
• Never auto-deserialize untrusted data (no eval(), no pickle.loads() on user input)

A09: Logging and Monitoring Failures

| 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 |

A10: Server-Side Request Forgery (SSRF)

• Validate and allowlist URLs before server-side requests
• Never allow users to control URLs for server-side fetches
• Block requests to internal networks (169.254.x.x, 10.x.x.x, 127.x.x.x, 192.168.x.x)

Security Headers

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.

Secrets Management

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

Input Validation Checklist

For every input field:

• [ ] Type validated (string, number, email, URL)
• [ ] Length constrained (minimum and maximum)
• [ ] Format validated (regex for structured data)
• [ ] Range checked (numbers, dates)
• [ ] Allowlisted where possible (enum values, known options)
• [ ] Sanitized for output context (HTML, SQL, shell)
• [ ] File uploads: type verified by content inspection (not extension), size limited

Cognitive Traps

| 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. |

Guardrails -- HALT and Fix

• String concatenation in SQL queries
• eval() or exec() on user-provided data
• Secrets in source code or committed configuration files
• Missing authorization checks on endpoints
• User input rendered without encoding
• Wildcard * CORS policy with credentials
• HTTP for anything involving authentication or sensitive data
• Client-side-only validation without server-side counterpart
• Disabled CSRF protection
• Default credentials in deployed environments

Every item on this list is a security vulnerability. Remediate before shipping.

Integration

Complementary skills:

• godmode:system-design -- Authentication strategy and data flow design
• godmode:quality-enforcement -- Security checks as automated quality gates
• godmode:completion-gate -- Security verification before shipping
• godmode:test-first -- Write security-focused test cases

The Bottom Line

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.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: NoobyGains
• Source: NoobyGains/godmode
• License: MIT

Install and usage instructions live in the source repository linked above.