Owasp Security Audit

OWASP Top 10 Security Audit

Overview

Systematic methodology for auditing web applications against the OWASP Top 10:2021. Combines automated tooling with manual code review, produces a prioritized remediation plan with verification steps and CI/CD integration guidance.

Core principle: Every finding must be verified with tooling or code evidence, prioritized by exploitability, and paired with a concrete fix the agent can implement.

When to Use

• Cybersecurity audit or security review request
• OWASP Top 10 compliance assessment
• Pre-release security gate or penetration test preparation
• Post-incident security hardening
• Dependency vulnerability triage

When NOT to use:

• Quick fix for a single known vulnerability (just fix it)
• General code quality review (use code-auditing skill instead)
• Infrastructure/cloud security review (out of scope - this covers application layer)

Audit Methodology

Phase 0: Environment Setup and Automated Scans

Run automated tools FIRST - they catch low-hanging fruit before manual review.

Required scans (execute all):

Record baseline metrics: Total vulnerabilities by severity, outdated dependency count, secret scan hits.

Phase 1: Systematic Category Audit

Audit EVERY category using the checklist in the Quick Reference section. Do not skip categories even if they seem irrelevant - document "N/A" with justification.

For each category:

1. Run the specific checks listed in the checklist
2. Record findings with file path, line number, and severity
3. Note what you checked even if clean (proves thoroughness)

Phase 2: Findings Classification

Rate each finding using this severity matrix:

Phase 3: Prioritized Remediation Plan

Group fixes into implementation phases:

Phase A - Immediate (< 1 day, critical/high):

• Rotate exposed credentials
• Add authentication middleware
• Install and configure Helmet
• Add rate limiting
• Fix .gitignore and purge secrets from git history

Phase B - Short-term (1-3 days, high/medium):

• Implement RBAC authorization
• Add input sanitization (xss/DOMPurify)
• Configure structured logging
• Set body size limits
• Add CSRF protection

Phase C - Medium-term (1-2 weeks, medium/low):

• Upgrade outdated dependencies
• Add CI/CD security pipeline
• Implement audit logging
• Add security monitoring/alerting

Each fix must include: what to change, where, a code example, and how to verify it works.

Phase 4: Verification and CI/CD Integration

For each remediation, define a verification step:

• Unit test that validates the security control
• curl command that proves the vulnerability is fixed
• CI pipeline check that prevents regression

Quick Reference: OWASP Top 10 Audit Checklist

A01: Broken Access Control

Step 1: Enumerate all routes first. Run rg 'router\.(get|post|put|patch|delete)' --glob '*.ts' and list every endpoint. Then verify EACH has auth middleware.

A02: Cryptographic Failures

A03: Injection

A04: Insecure Design

A05: Security Misconfiguration

A06: Vulnerable and Outdated Components

A07: Identification and Authentication Failures

A08: Software and Data Integrity Failures

A09: Security Logging and Monitoring Failures

A10: Server-Side Request Forgery (SSRF)

Serverless/Lambda Specific Checks

If the project deploys to AWS Lambda (or similar FaaS), also check:

Runtime Verification Commands

After implementing fixes, verify with actual HTTP requests:

# Verify Helmet headers
curl -sI http://localhost:3010/ | grep -iE '(x-powered-by|x-content-type|strict-transport|x-frame)'

# Verify rate limiting
for i in $(seq 1 110); do curl -s -o /dev/null -w "%{http_code}\n" http://localhost:3010/; done | sort | uniq -c

# Verify CORS rejects unknown origins
curl -sI -H "Origin: http://evil.com" http://localhost:3010/ | grep -i access-control

# Verify body size limit
python3 -c "print('x'*2000000)" | curl -s -X POST -H "Content-Type: application/json" -d @- http://localhost:3010/candidates -w "\n%{http_code}"

# Verify auth required
curl -s http://localhost:3010/candidates -w "\n%{http_code}"

Report Template

# OWASP Top 10 Security Audit Report

- **Project**: [name]
- **Stack**: [technologies]
- **Date**: [YYYY-MM-DD]
- **Scope**: Static code analysis + automated tooling

## Automated Scan Results

### npm audit
- Critical: X | High: X | Medium: X | Low: X
- Key vulnerabilities: [list]

### Secret Scan
- Hits: X
- Locations: [list]

## Findings by Category

### A01: Broken Access Control — [CRITICAL/HIGH/MEDIUM/LOW/CLEAN]
**Checked:** [list what was examined]
**Findings:** [list with file:line references]
**Remediation:** [code examples]

[...repeat for A02-A10...]

## Remediation Priority Matrix

| Phase | Finding | Severity | Effort | Fix |
|-------|---------|----------|--------|-----|
| A | [finding] | Critical | [hours] | [brief description] |

## Verification Checklist
- [ ] [Finding 1]: [how to verify fix]
- [ ] [Finding 2]: [how to verify fix]

## CI/CD Security Integration
- [ ] `npm audit` in CI pipeline (fail on critical/high)
- [ ] ESLint security plugin in pre-commit hook
- [ ] Dependency update bot (Dependabot/Renovate)
- [ ] Secret scanning in CI (truffleHog/gitleaks)

Common Mistakes

Node.js/Express Specific Hardening Checklist

Essential middleware stack (order matters):

import helmet from 'helmet';
import rateLimit from 'express-rate-limit';
import cors from 'cors';
import hpp from 'hpp';

// 1. Security headers
app.use(helmet());
app.disable('x-powered-by');

// 2. Rate limiting
app.use(rateLimit({
  windowMs: 15 * 60 * 1000,
  max: 100,
  standardHeaders: true,
  legacyHeaders: false,
}));

// 3. CORS - explicit origins only
app.use(cors({
  origin: process.env.ALLOWED_ORIGINS?.split(',') || [],
  credentials: true,
  methods: ['GET', 'POST', 'PUT', 'PATCH', 'DELETE'],
}));

// 4. Body parsing with size limits
app.use(express.json({ limit: '1mb' }));
app.use(express.urlencoded({ extended: true, limit: '1mb' }));

// 5. HTTP Parameter Pollution protection
app.use(hpp());

// 6. Request logging (BEFORE routes)
app.use(requestLogger);

// 7. Routes
app.use('/api', routes);

// 8. Error handler (AFTER routes, generic messages only)
app.use(errorHandler);

Prisma/ORM Security Notes

• Always use select to limit returned fields (avoid PII leakage)
• Never trust env() in schema.prisma if the .env is committed
• Watch for validation bypass when id is present in request body
• Prisma prevents SQL injection but NOT mass assignment - validate allowed fields explicitly

Source: LIDR-academy/AI4Devs-LTI-extended — distributed by TomeVault.