---
name: security-best-practices
description: Apply security hardening, input validation, and protection measures across all operations
---

## When to use
Use when the user asks to:
- Secure an application or system
- Audit code for vulnerabilities
- Set up authentication/authorization
- Harden configurations
- Perform security reviews
- Handle secrets and credentials

## Core Principles

### 1. Defense in Depth
Apply multiple layers of security:
- Input validation
- Authentication
- Authorization
- Output encoding
- Encryption
- Auditing

### 2. Least Privilege
Agents/tools should have only the permissions they need:
- File access: restrict to specific directories
- Network: allow only required endpoints
- Tools: disable dangerous ones when not needed

### 3. Fail Securely
Errors should not reveal sensitive information:
- Generic error messages to users
- Detailed errors only in logs (protected)
- Secure defaults (deny by default)

## Security Checklist

### Input Validation
- [ ] Validate all user inputs (type, length, format, range)
- [ ] Sanitize to remove/escape dangerous characters
- [ ] Use parameterized queries (no string concatenation)
- [ ] Reject unexpected values early

### Authentication & Authorization
- [ ] Use strong, salted password hashing (bcrypt, Argon2)
- [ ] Implement multi-factor authentication for sensitive operations
- [ ] Enforce least privilege (RBAC/ABAC)
- [ ] Use short-lived tokens, rotate regularly
- [ ] Validate permissions on every request

### Secrets Management
- [ ] Never hardcode secrets in source code
- [ ] Use environment variables or secret vaults
- [ ] Rotate credentials regularly
- [ ] Different secrets per environment (dev/staging/prod)
- [ ] Don't log secrets (redact from logs)

### Data Protection
- [ ] Encrypt sensitive data at rest (AES-256)
- [ ] Use TLS 1.2+ for data in transit
- [ ] Secure backups (encrypted, access-controlled)
- [ ] Anonymize/pseudonymize PII when possible

### Output Encoding
- [ ] Encode data before rendering (HTML escape, SQL escape, shell escape)
- [ ] Use templating engines with auto-escaping
- [ ] Content Security Policy (CSP) headers for web apps

### Dependency Security
- [ ] Regularly audit dependencies for CVEs
- [ ] Use minimal dependencies
- [ ] Pin versions (avoid floating ranges)
- [ ] Update promptly when vulnerabilities disclosed

## Code Review Security Points

Review code for:
- **SQL injection**: raw queries with string concatenation
- **XSS**: unescaped output in HTML/JS
- **CSRF**: missing tokens on state-changing requests
- **Path traversal**: user-controlled file paths without validation
- **Insecure deserialization**: untrusted data → object creation
- **Hardcoded secrets**: passwords, API keys in source
- **Weak crypto**: MD5, SHA1, custom algorithms, hardcoded keys

## Configuration Hardening

### File permissions
```bash
chmod 600 ~/.openclaw/credentials/*.json  # Owner read/write only
chmod 700 ~/.openclaw/workspace          # Restrict workspace
```

### Network security
- Firewall: allow only necessary ports
- VPN for remote access
- Disable unnecessary services

### Audit logging
Log all security events:
- Authentication attempts (success/failure)
- Authorization failures
- Configuration changes
- Data access (especially PII)
Include: timestamp, user, action, IP, outcome

## Incident Response

If a breach is suspected:
1. **Isolate**: Cut off network access if possible
2. **Preserve logs**: Don't delete; copy for analysis
3. **Assess scope**: Which systems/data affected?
4. **Notify**: Follow disclosure procedures
5. **Remediate**: Patch vulnerabilities, rotate credentials
6. **Post-mortem**: Document lessons learned

## Tools for Security Audit

Use OpenClaw skills:
- `security-review`: Automated code security scan
- `systematic-debugging`: Identify root cause of vulnerabilities
- `code-quality-gate`: Enforce security standards

External tools:
- OWASP ZAP / Burp Suite (web scanning)
- Trivy / Grype (dependency scanning)
- Bandit / Semgrep (SAST)
- sqlmap (SQL injection testing)

## Examples

<Good>
Database query with parameterized statement:
```python
cursor.execute("SELECT * FROM users WHERE email = %s", (email,))
```
</Good>

<Bad>
```python
query = f"SELECT * FROM users WHERE email = '{email}'"
cursor.execute(query)  # SQL injection vulnerability
```
</Bad>

## Compliance Considerations

Depending on industry:
- **GDPR**: Data protection, privacy by design, breach notification
- **PCI DSS**: Payment card data handling
- **HIPAA**: Healthcare data encryption and access logs
- **SOC 2**: Security controls and audit trails

## Verification Checklist
- [ ] All user inputs validated and sanitized
- [ ] No hardcoded secrets in codebase
- [ ] Secrets stored securely (env vars, vault)
- [ ] Database queries use parameterized statements
- [ ] Output properly encoded for context (HTML, SQL, shell)
- [ ] Authentication strong (bcrypt, 2FA)
- [ ] Authorization checks on all protected actions
- [ ] Sensitive data encrypted at rest and in transit
- [ ] Audit logs capture security events
- [ ] Dependencies up-to-date with no known CVEs
- [ ] Regular security scans performed
- [ ] Incident response plan documented