# Security Protocol

> 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

- Skill: `noobygains/security-protocol` (Agent Skill)
- Install (CLI): `npx skillmds@latest add noobygains/security-protocol`
- Raw SKILL.md: https://api.skillmd.com/api/skills/noobygains/security-protocol/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: noobygains (https://skillmd.com/u/noobygains)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/noobygains/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 |

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