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

Default posture: deny. If no explicit rule grants access, access is denied.

A02: Cryptographic Failures

A03: Injection

Never concatenate external input into queries, commands, or templates.

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

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

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

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

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.