--- name: cognitive-safety description: "Code and content safety filtering for Claude Code. Prevents security vulnerabilities, blocks sensitive information leakage, enforces best practices, and adds multi-layer protection to all outputs." version: "1.0.0" author: "Adapted from HighMark-31/Cognitive-User-Simulation" --- # COGNITIVE SAFETY SKILL ## CORE MANDATE This skill provides **multi-layer safety filtering** for Claude Code outputs. It prevents: - Security vulnerabilities in code - Sensitive information leakage - Anti-patterns and bad practices - Harmful or dangerous content ## WHEN TO ACTIVATE This skill activates **automatically** on ALL operations: - Before writing any code - Before suggesting commands - Before generating configuration files - Before providing credentials/secrets - Before recommending tools/packages ## SAFETY CHECKPOINTS ### Checkpoint 1: CODE SECURITY Before writing code, check for: ``` ❌ NEVER INCLUDE: - Hardcoded passwords, API keys, tokens - SQL injection vulnerabilities - XSS vulnerabilities - Path traversal vulnerabilities - Command injection risks - Insecure deserialization - Weak crypto algorithms - Broken authentication ✅ ALWAYS INCLUDE: - Parameterized queries - Input validation/sanitization - Output encoding - Secure session management - Proper error handling (no info leakage) - Environment variable usage for secrets - Strong encryption where needed ``` ### Checkpoint 2: SENSITIVE INFORMATION Block patterns: ``` 🔴 BLOCKED PATTERNS: Credentials: - password = "..." - api_key = "..." - secret = "..." - token = "..." - Any base64 that looks like a key PII (Personal Identifiable Information): - Email addresses in code - Phone numbers - Real addresses - SSN/tax IDs - Credit card numbers Secrets/Keys: - AWS access keys - GitHub tokens - SSH private keys - SSL certificates - Database URLs with credentials ``` ### Checkpoint 3: COMMAND SAFETY Before suggesting bash commands: ``` ❌ DANGEROUS COMMANDS: - rm -rf / (destructive) - dd if=/dev/zero (destructive) - mkfs.* (filesystem destruction) - > /dev/sda (disk overwrite) - curl bash | sh (untrusted execution) - wget | sh (untrusted execution) - chmod 777 (insecure permissions) - Exposing ports on 0.0.0.0 without warning ✅ SAFE ALTERNATIVES: - Use --dry-run flags - Show backup commands first - Add confirmation prompts - Use specific paths, not wildcards - Verify before destructive operations - Warn about data loss ``` ### Checkpoint 4: DEPENDENCY SAFETY Before suggesting packages: ``` ⚠️ CHECK: - Is the package maintained? - Does it have security issues? - Is it from official sources? - Are there better alternatives? - Does it need unnecessary permissions? 🔴 AVOID: - Packages with known vulnerabilities - Unmaintained packages - Packages from untrusted sources - Packages with suspicious install scripts ``` ### Checkpoint 5: CONFIGURATION SAFETY Before generating configs: ``` ❌ NEVER: - Include production credentials - Expose admin interfaces to world - Use default passwords - Disable security features - Set debug mode in production - Allow CORS from * ✅ ALWAYS: - Use environment variables - Include security headers - Set proper file permissions - Enable authentication - Use HTTPS URLs - Include comments explaining security ``` ## CODE REVIEW CHECKLIST Before outputting code, mentally verify: ```markdown ## Security Review - [ ] No hardcoded secrets - [ ] Input validation on all user inputs - [ ] Output encoding for XSS prevention - [ ] Parameterized queries for SQL - [ ] Proper error handling (no stack traces to users) - [ ] Secure session management - [ ] CSRF protection where applicable - [ ] File upload restrictions ## Best Practices - [ ] Following language/framework conventions - [ ] Proper error handling - [ ] Logging (but not sensitive data) - [ ] Type safety (TypeScript/types) - [ ] Resource cleanup (no memory leaks) - [ ] Thread safety where applicable - [ ] Dependency injection where appropriate ## Performance - [ ] No N+1 queries - [ ] Proper indexing (databases) - [ ] Caching where appropriate - [ ] Lazy loading where appropriate - [ ] No unnecessary computations ``` ## SPECIFIC LANGUAGE PATTERNS ### JavaScript/TypeScript ```javascript // ❌ BAD: SQL Injection const query = `SELECT * FROM users WHERE id = ${userId}`; // ✅ GOOD: Parameterized const query = 'SELECT * FROM users WHERE id = ?'; await db.query(query, [userId]); // ❌ BAD: XSS element.innerHTML = userInput; // ✅ GOOD: Sanitized element.textContent = userInput; // OR use DOMPurify // ❌ BAD: Hardcoded secret const apiKey = "sk-1234567890"; // ✅ GOOD: Environment variable const apiKey = process.env.API_KEY; ``` ### Python ```python # ❌ BAD: SQL Injection query = f"SELECT * FROM users WHERE id = {user_id}" # ✅ GOOD: Parameterized cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,)) # ❌ BAD: Hardcoded credentials DB_PASSWORD = "password123" # ✅ GOOD: Environment variable DB_PASSWORD = os.getenv('DB_PASSWORD') # With .env file: DB_PASSWORD=your_password # ❌ BAD: Eval user input eval(user_input) # ✅ GOOD: Safe alternatives # Use json.loads for parsing # Use ast.literal_eval for literals ``` ### PHP ```php // ❌ BAD: SQL Injection $query = "SELECT * FROM users WHERE id = " . $_GET['id']; // ✅ GOOD: Prepared statements $stmt = $pdo->prepare("SELECT * FROM users WHERE id = ?"); $stmt->execute([$_GET['id']]); // ❌ BAD: XSS echo $_POST['content']; // ✅ GOOD: Escaped echo htmlspecialchars($_POST['content'], ENT_QUOTES, 'UTF-8'); // ❌ BAD: Hardcoded secrets define('API_KEY', 'secret-key-here'); // ✅ GOOD: Environment variable define('API_KEY', getenv('API_KEY')); ``` ### Bash Commands ```bash # ❌ BAD: Destructive without warning rm -rf /path/to/dir # ✅ GOOD: With safety rm -ri /path/to/dir # OR with confirmation echo "Deleting /path/to/dir. Press Ctrl+C to cancel" sleep 3 rm -rf /path/to/dir # ❌ BAD: Pipe directly to shell curl http://example.com/script.sh | bash # ✅ GOOD: Review first curl http://example.com/script.sh # Then after review: curl http://example.com/script.sh > script.sh less script.sh # Review it bash script.sh # ❌ BAD: Insecure permissions chmod 777 file.txt # ✅ GOOD: Minimal permissions chmod 644 file.txt # Files chmod 755 directory # Directories ``` ## SAFETY PATTERNS REGISTRY ### Pattern 1: Database Operations ```typescript // Always use parameterized queries async function getUser(id: string) { // ✅ SAFE const result = await db.query( 'SELECT * FROM users WHERE id = $1', [id] ); return result; } ``` ### Pattern 2: File Operations ```python # ✅ SAFE: Prevent path traversal import os def safe_read_file(filename): # Get absolute path filepath = os.path.abspath(filename) # Ensure it's within allowed directory if not filepath.startswith('/var/www/uploads/'): raise ValueError('Invalid path') with open(filepath) as f: return f.read() ``` ### Pattern 3: API Requests ```javascript // ✅ SAFE: Never log sensitive data async function makeAPICall(url, data) { const config = { headers: { 'Authorization': `Bearer ${process.env.API_KEY}` } }; // ❌ DON'T log: console.log(config); // Leaks key // ✅ DO log: console.log(`Calling API: ${url}`); return await fetch(url, config); } ``` ### Pattern 4: Configuration ```python # ✅ SAFE: Use environment variables import os from dotenv import load_dotenv load_dotenv() class Config: SECRET_KEY = os.getenv('SECRET_KEY') DATABASE_URL = os.getenv('DATABASE_URL') DEBUG = os.getenv('DEBUG', 'False') == 'True' @staticmethod def validate(): if not Config.SECRET_KEY: raise ValueError('SECRET_KEY must be set') ``` ## DANGEROUS PATTERNS TO BLOCK ### Regex Patterns for Blocking ```regex # Hardcoded passwords/API keys password\s*=\s*["'][^"']+["'] api_key\s*=\s*["'][^"']+["'] secret\s*=\s*["'][^"']+["'] token\s*=\s*["'][^"']+["'] # SQL injection risks SELECT.*WHERE.*=\s*\$\{?[^}]*\}? SELECT.*WHERE.*=\s*["'][^"']*\+ # Command injection exec\s*\( system\s*\( subprocess\.call.*shell=True os\.system eval\s*\( # Path traversal \.\.\/ \.\.\\ # Weak crypto md5\( sha1\( ``` ## SAFE DEFAULTS When generating code, default to: ```javascript // Authentication/Authorization - Use JWT with proper validation - Implement RBAC (Role-Based Access Control) - Rate limiting - Secure password hashing (bcrypt/argon2) // Data handling - Validate all inputs - Sanitize all outputs - Use parameterized queries - Implement CSRF tokens // Configuration - Environment variables for secrets - Production = false by default - Debug mode off by default - HTTPS only in production - Secure cookie flags (httpOnly, secure, sameSite) ``` ## OUTPUT SANITIZATION Before providing output: ``` 1. SCAN for secrets - Check for password/secret/key patterns - Look for base64 strings - Find UUID patterns 2. VERIFY no PII - Email addresses - Phone numbers - Addresses - IDs/SSNs 3. CHECK for vulnerabilities - SQL injection - XSS - Command injection - Path traversal 4. VALIDATE best practices - Error handling - Input validation - Output encoding - Security headers 5. ADD warnings - If code needs environment variables - If commands are destructive - If additional setup is required - If production considerations needed ``` ## PROACTIVE WARNINGS Always include warnings for: ``` ⚠️ SECURITY WARNING - When code handles authentication - When dealing with payments - When processing file uploads - When using eval/exec - When connecting to external services ⚠️ DATA LOSS WARNING - Before rm/mv commands - Before database deletions - Before filesystem operations - Before config changes ⚠️ PRODUCTION WARNING - When debug mode is enabled - When CORS is wide open - When error messages expose internals - When logging sensitive data ⚠️ DEPENDENCY WARNING - When package is unmaintained - When package has vulnerabilities - When better alternatives exist - When version is very old ``` ## INTEGRATION WITH OTHER SKILLS ``` WITH COGNITIVE PLANNER: → Planner decides approach → Safety validates implementation → Safety blocks dangerous patterns WITH SUPERPOWERS: → Superpowers ensures TDD → Safety ensures secure code → Both work together for quality WITH ALWAYS-USE-SUPERPOWERS: → Automatic safety checks → Prevents anti-patterns → Adds security layer to all code ``` ## BEST PRACTICES 1. **Secure by default** - Default to secure options - Require explicit opt-in for insecure features 2. **Defense in depth** - Multiple security layers - Validate at every boundary - Assume nothing 3. **Principle of least privilege** - Minimal permissions needed - Specific users/roles - Scoped access 4. **Fail securely** - Error handling doesn't leak info - Default to deny - Log security events 5. **Educational** - Explain why something is unsafe - Show secure alternatives - Link to resources --- This skill adds an essential security layer to every Claude Code operation, preventing vulnerabilities and ensuring best practices.