eng-security-audit
Security Audit Skill
Core Principle
Never trust anything from outside your control. Every external input is a potential attack vector.
Phase 1: Threat Surface Mapping
Before auditing, identify what you're protecting and where attacks can come from.
Questions to Answer
- What sensitive data does this app handle? (PII, payments, auth tokens, health data)
- What are all the entry points? (APIs, forms, file uploads, webhooks, URL params)
- What external services does it connect to? (databases, third-party APIs, cloud services)
- Who are the user types and what should each access?
- What's the deployment environment? (cloud provider, containers, serverless)
Output
## Threat Surface Map
**Sensitive Data:**
- [List all sensitive data types and where they're stored]
**Entry Points:**
- [List all ways data enters the system]
**External Connections:**
- [List all third-party integrations and data flows]
**User Roles:**
- [List roles and their intended access levels]
**Infrastructure:**
- [Deployment environment details]
Phase 2: Vulnerability Audit Checklist
Work through each category systematically. Flag issues with severity levels.
Severity Levels
- CRITICAL: Immediate exploitation possible, data breach or system takeover risk
- HIGH: Exploitable with some effort, significant damage potential
- MEDIUM: Requires specific conditions, limited impact
- LOW: Minor issue, defense-in-depth concern
2.1 Input Validation & Sanitization
Check for:
[ ] SQL Injection
- Are all database queries parameterized?
- Any string concatenation in SQL statements?
- ORMs configured to prevent raw query injection?
[ ] XSS (Cross-Site Scripting)
- Is user input escaped before rendering in HTML?
- Are Content-Security-Policy headers set?
- React/Vue auto-escaping relied upon correctly?
- Any use of dangerouslySetInnerHTML or v-html?
[ ] Command Injection
- Any user input passed to shell commands?
- Using child_process, exec, eval, or system calls?
[ ] Path Traversal
- File paths constructed from user input?
- Checking for ../ sequences?
- Restricting file access to intended directories?
[ ] SSRF (Server-Side Request Forgery)
- URLs accepted from users for fetching?
- Validating/whitelisting allowed domains?
- Blocking internal IP ranges (127.0.0.1, 10.x, 192.168.x)?
[ ] XML/JSON Injection
- External entity processing disabled in XML parsers?
- JSON parsing with strict mode?
[ ] Input Boundaries
- Maximum lengths enforced on all inputs?
- File upload size limits?
- Rate limiting on input endpoints?
- Type checking (expecting number, getting string)?
Common Vulnerable Patterns:
// BAD: SQL Injection
const query = `SELECT * FROM users WHERE id = ${userId}`;
// GOOD: Parameterized
const query = 'SELECT * FROM users WHERE id = ?';
db.query(query, [userId]);
// BAD: Command Injection
exec(`convert ${userFilename} output.png`);
// GOOD: Avoid shell, use specific args
execFile('convert', [sanitizedFilename, 'output.png']);
// BAD: Path Traversal
const file = fs.readFileSync(`./uploads/${userInput}`);
// GOOD: Validate and restrict
const safePath = path.basename(userInput);
const fullPath = path.join(UPLOAD_DIR, safePath);
if (!fullPath.startsWith(UPLOAD_DIR)) throw new Error('Invalid path');
2.2 Authentication
Check for:
[ ] Password Security
- Passwords hashed with bcrypt/argon2/scrypt? (NOT md5/sha1)
- Salt unique per password?
- Minimum password complexity enforced?
- Password breach checking (HaveIBeenPwned API)?
[ ] Session Management
- Session tokens cryptographically random?
- Tokens regenerated after login?
- Session timeout implemented?
- Secure and HttpOnly flags on session cookies?
- SameSite attribute set?
[ ] JWT Security (if applicable)
- Algorithm explicitly set (not 'none')?
- Secret key strong and not hardcoded?
- Token expiration enforced?
- Sensitive data excluded from payload?
- Refresh token rotation implemented?
[ ] Multi-Factor Authentication
- Available for sensitive accounts?
- Backup codes properly secured?
- TOTP implementation using established libraries?
[ ] Brute Force Protection
- Account lockout after failed attempts?
- Progressive delays?
- CAPTCHA after threshold?
- IP-based rate limiting?
[ ] Password Reset
- Reset tokens single-use and time-limited?
- Token transmitted securely (HTTPS only)?
- Old sessions invalidated after reset?
- No username enumeration via reset flow?
Common Vulnerable Patterns:
// BAD: Weak hashing
const hash = crypto.createHash('md5').update(password).digest('hex');
// GOOD: Use bcrypt
const hash = await bcrypt.hash(password, 12);
// BAD: Predictable session
const sessionId = `user_${Date.now()}`;
// GOOD: Cryptographically random
const sessionId = crypto.randomBytes(32).toString('hex');
// BAD: JWT with no expiration
const token = jwt.sign({ userId }, secret);
// GOOD: Short expiration
const token = jwt.sign({ userId }, secret, { expiresIn: '15m' });
2.3 Authorization (Access Control)
Check for:
[ ] IDOR (Insecure Direct Object Reference)
- Every data access checks user ownership?
- API endpoints verify user can access requested resource?
- No reliance on obscurity of IDs?
[ ] Privilege Escalation
- Role checks on every privileged action?
- Admin functions properly gated?
- Can users modify their own role?
[ ] Horizontal Access
- User A cannot access User B's data by changing IDs?
- Bulk operations check permissions on all items?
[ ] Vertical Access
- Regular users cannot access admin endpoints?
- Role hierarchy properly enforced?
[ ] Function-Level Access
- Every API endpoint has authorization check?
- Default deny policy in place?
- Middleware consistently applied?
Common Vulnerable Patterns:
// BAD: No ownership check
app.get('/api/documents/:id', async (req, res) => {
const doc = await Document.findById(req.params.id);
res.json(doc);
});
// GOOD: Verify ownership
app.get('/api/documents/:id', async (req, res) => {
const doc = await Document.findOne({
_id: req.params.id,
userId: req.user.id // Must belong to requesting user
});
if (!doc) return res.status(404).json({ error: 'Not found' });
res.json(doc);
});
// BAD: Role in client-controlled data
const isAdmin = req.body.isAdmin;
// GOOD: Role from verified session
const isAdmin = req.user.role === 'admin';
2.4 Secrets Management
Check for:
[ ] No Hardcoded Secrets
- API keys not in source code?
- Database credentials externalized?
- No secrets in client-side code?
- Git history clean of committed secrets?
[ ] Environment Variables
- .env files in .gitignore?
- Production secrets not in version control?
- Different secrets per environment?
[ ] Secret Storage
- Using secret manager (AWS Secrets Manager, Vault, etc.)?
- Secrets encrypted at rest?
- Access to secrets audited?
[ ] Key Rotation
- Process for rotating compromised keys?
- Services handle rotation gracefully?
[ ] Exposure Prevention
- Secrets not logged?
- Error messages don't leak secrets?
- Secrets not in URLs?
Audit Commands:
# Search for potential secrets in codebase
grep -r "api_key\|apikey\|secret\|password\|token" --include="*.js" --include="*.ts" --include="*.py" --include="*.env*"
# Check git history for secrets
git log -p | grep -i "password\|secret\|api_key\|token"
# Use tools like truffleHog or git-secrets
trufflehog git file://./
2.5 Dependency Security
Check for:
[ ] Known Vulnerabilities
- npm audit / pip audit / cargo audit run?
- All critical/high vulnerabilities addressed?
- Automated scanning in CI/CD?
[ ] Dependency Hygiene
- Lock files committed (package-lock.json, yarn.lock)?
- Versions pinned appropriately?
- Unused dependencies removed?
[ ] Supply Chain
- Dependencies from trusted sources?
- Typosquatting checks on package names?
- Recent ownership changes investigated?
- Minimal dependency tree preferred?
[ ] Update Policy
- Regular update schedule?
- Security updates prioritized?
- Breaking changes tested before deployment?
Audit Commands:
# Node.js
npm audit
npm outdated
# Python
pip-audit
safety check
# Go
go list -m all | nancy sleuth
# General
snyk test
2.6 API Security
Check for:
[ ] Transport Security
- HTTPS enforced everywhere?
- HSTS header set?
- TLS 1.2+ only?
- Certificate valid and not expiring soon?
[ ] Rate Limiting
- Per-user and per-IP limits?
- Limits on expensive operations?
- Graduated response (warn, throttle, block)?
[ ] CORS Configuration
- Origins explicitly whitelisted (not *)?
- Credentials mode properly configured?
- Preflight caching appropriate?
[ ] Request Validation
- Schema validation on all endpoints?
- Unexpected fields rejected or ignored?
- Content-Type enforcement?
[ ] Response Security
- Sensitive data filtered from responses?
- Error messages don't leak internals?
- Pagination prevents data dumps?
- No stack traces in production?
[ ] API Authentication
- Tokens transmitted in headers (not URL)?
- Token validation on every request?
- Scope/permission checking?
Secure Headers Checklist:
Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy: default-src 'self'
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: geolocation=(), camera=(), microphone=()
2.7 Database Security
Check for:
[ ] Access Control
- Application uses least-privilege database user?
- No shared credentials between environments?
- Database not publicly accessible?
[ ] Query Safety
- All queries parameterized?
- ORM configured safely?
- Raw queries reviewed carefully?
[ ] Data Protection
- Sensitive fields encrypted at rest?
- PII handling compliant with regulations?
- Backups encrypted?
[ ] Connection Security
- SSL/TLS for database connections?
- Connection pooling configured?
- Idle connections terminated?
2.8 File Upload Security
Check for:
[ ] File Validation
- File type validated by content (magic bytes), not just extension?
- Maximum file size enforced?
- Filename sanitized?
[ ] Storage Security
- Files stored outside web root?
- No direct execution of uploaded files?
- Unique/random filenames generated?
[ ] Malware Prevention
- Virus scanning on uploads?
- Image re-encoding to strip malicious payloads?
[ ] Access Control
- Uploaded files access-controlled?
- Signed URLs for temporary access?
Dangerous File Types to Block:
.exe, .dll, .bat, .cmd, .sh, .php, .jsp, .asp, .aspx,
.cgi, .pl, .py, .rb, .jar, .war, .htaccess, .config,
.svg (can contain scripts), .html, .htm
2.9 Error Handling & Logging
Check for:
[ ] Error Messages
- Generic errors shown to users?
- Stack traces disabled in production?
- No sensitive data in error responses?
[ ] Logging Security
- Sensitive data redacted from logs?
- Logs stored securely?
- Log injection prevented?
[ ] Security Event Logging
- Authentication attempts logged?
- Authorization failures logged?
- Admin actions logged?
- Logs include timestamp, user, IP, action?
[ ] Monitoring
- Alerting on suspicious patterns?
- Anomaly detection in place?
- Incident response plan documented?
2.10 Infrastructure & Deployment
Check for:
[ ] Server Hardening
- Unnecessary services disabled?
- Default credentials changed?
- OS and packages updated?
- Firewall configured?
[ ] Container Security (if applicable)
- Base images from trusted sources?
- Images scanned for vulnerabilities?
- Running as non-root user?
- Secrets not baked into images?
[ ] Cloud Configuration
- S3 buckets not public by default?
- IAM roles follow least privilege?
- Security groups restrictive?
- CloudTrail/audit logging enabled?
[ ] CI/CD Security
- Secrets not exposed in build logs?
- Dependencies verified during build?
- Deployment requires approval for production?
- Infrastructure as code reviewed?
Phase 3: Report Generation
After completing the audit, produce a structured report.
Report Format
# Security Audit Report
**Project:** [Name]
**Date:** [Date]
**Auditor:** [Name/AI]
**Scope:** [What was reviewed]
## Executive Summary
[2-3 sentences on overall security posture and critical findings]
## Critical Findings
[Issues requiring immediate attention]
### Finding 1: [Title]
- **Severity:** CRITICAL
- **Location:** [File/endpoint]
- **Description:** [What's wrong]
- **Impact:** [What could happen]
- **Remediation:** [How to fix]
- **Code Example:** [Before/after if applicable]
## High Priority Findings
[Same format as critical]
## Medium Priority Findings
[Same format]
## Low Priority Findings
[Same format]
## Recommendations
[General improvements beyond specific findings]
## What's Working Well
[Positive security practices observed]
Phase 4: Remediation Guidance
When fixing issues, follow this priority:
- Critical: Fix immediately, consider taking affected systems offline
- High: Fix within 24-48 hours
- Medium: Fix within current sprint
- Low: Add to backlog, fix opportunistically
Remediation Principles
- Fix the root cause, not just the symptom
- Add tests that would catch the vulnerability
- Review similar code for same pattern
- Update documentation/guidelines to prevent recurrence
- Consider defense in depth (multiple layers)
Quick Reference: Common Vulnerability Patterns
| Vulnerability | What to Look For | Fix |
|---|---|---|
| SQL Injection | String concat in queries | Parameterized queries |
| XSS | User input in HTML | Escape output, CSP |
| CSRF | State-changing GET, no tokens | CSRF tokens, SameSite cookies |
| IDOR | Direct object access without auth check | Verify ownership on every request |
| Broken Auth | Weak passwords, no lockout | Strong hashing, rate limiting |
| Security Misconfiguration | Default settings, verbose errors | Harden configs, generic errors |
| Sensitive Data Exposure | Plaintext storage, weak crypto | Encryption, proper key management |
| XXE | XML parsing enabled | Disable external entities |
| Broken Access Control | Missing role checks | Default deny, check every action |
| Insecure Deserialization | Untrusted data deserialized | Avoid or sign serialized data |
Tools Reference
Static Analysis
- JavaScript/TypeScript: ESLint security plugins, Semgrep
- Python: Bandit, Safety
- General: SonarQube, Snyk Code
Dependency Scanning
- npm audit, Snyk, Dependabot, OWASP Dependency-Check
Dynamic Testing
- OWASP ZAP, Burp Suite, Nikto
Secret Detection
- truffleHog, git-secrets, Gitleaks
Infrastructure
- ScoutSuite (cloud), Trivy (containers), Prowler (AWS)
More from hungv47/agent-skills
design-user-flow
This skill should be used when the user asks to "create a user flow", "map navigation", "design user journey", "create wireflow", "plan screen transitions", "map the app flow", "design navigation", or mentions user flow, wireflow, navigation map, user journey, screen transitions, or pre-interface design research. Creates user flow diagrams and wireflows for digital products.
14eng-system-architecture
This skill should be used when the user asks to "design system architecture", "plan the tech stack", "create database schema", "design API structure", "architect the system", "plan the backend", "design infrastructure", or mentions system architecture, technical architecture, database design, API design, or tech stack selection. Transforms product documentation into comprehensive technical blueprints.
13mkt-diagnosis
This skill should be used when the user asks to "diagnose the problem", "break down the issue", "build a logic tree", "what's causing this", or mentions problem diagnosis, logic trees, MECE decomposition, or structured problem solving. This is the ENTRY POINT for problem analysis — use when no diagnosis exists yet.
13mkt-lp-optimization
This skill should be used when the user asks to "optimize a landing page", "improve conversion rates", "review my landing page", "create a high-converting landing page", "audit my LP", "reduce bounce rate", or mentions landing page design, conversion optimization, A/B testing strategy, or CTA optimization.
13mkt-imc
This skill should be used when the user asks to "create an IMC plan", "develop integrated marketing", "build a campaign strategy", "plan a product launch", or mentions IMC, integrated marketing, multi-channel marketing, or campaign planning.
13design-brand-system-generation
This skill should be used when the user asks to "create a design system", "build brand identity", "create brand guidelines", "define brand voice", "define design tokens", "create typography system", "define color palette", "create component patterns", "design UI system", "generate style guide", "brand strategy", "brand personality", "brand archetype", "render brand guidelines", "visual brand guideline", "brand guideline artboards", "design in Paper", or mentions design system, brand identity, brand guidelines, brand voice, brand personality, design tokens, typography, color palette, component specifications, or visual design standards. Transforms product documentation into comprehensive brand identity and design systems — from strategy and personality to visual identity, design tokens, and component specifications — with optional visual brand guideline artboards rendered in Paper MCP.
12