Api Security Audit

Performs comprehensive security audit of REST and GraphQL APIs, checking for OWASP API Security Top 10 vulnerabilities, authentication/authorization flaws, injection risks, and business logic issues.

What This Command Does

Complete API Security Assessment:

• Tests for OWASP API Security Top 10 vulnerabilities
• Validates authentication and authorization mechanisms
• Checks for injection vulnerabilities (SQL, NoSQL, command)
• Identifies excessive data exposure and mass assignment
• Tests rate limiting and resource consumption controls
• Analyzes GraphQL-specific security issues (deep queries, introspection)
• Reviews API documentation for security misconfigurations

Output: Detailed security audit report with exploitability ratings and remediation guidance

Time: 15-30 minutes per API

When to Use This Command

Perfect For:

• Pre-production API security validation
• External API security assessments
• Compliance requirements (PCI DSS, HIPAA)
• After API changes or new endpoint additions
• Regular security audits (quarterly)

Use This When:

• Building new API endpoints
• Before public API launch
• After authentication/authorization changes
• Responding to security incidents
• Preparing for penetration test

Usage

# Audit REST API
/api-security-audit https://api.example.com

# Audit GraphQL API
/api-security-audit https://api.example.com/graphql --type graphql

# Audit with authentication
/api-security-audit https://api.example.com --auth "Bearer TOKEN"

# Audit specific endpoints
/api-security-audit https://api.example.com/users --endpoints /users,/orders

# Generate detailed report
/api-security-audit https://api.example.com --output api-security-report.md

Shortcut:

/asa https://api.example.com  # Quick audit

OWASP API Security Top 10 Coverage

API1:2023 - Broken Object Level Authorization (BOLA/IDOR)

Vulnerability: Users can access objects belonging to other users

Example Attack:

# User 123 accesses their own order
GET /api/orders/456
Authorization: Bearer USER_123_TOKEN

# Attack: Change order ID to access other user's order
GET /api/orders/789  # ← Belongs to User 456!
Authorization: Bearer USER_123_TOKEN

# If API doesn't validate ownership, User 123 can see User 456's order

Detection Method:

# Test IDOR vulnerability
1. Create two test users (User A, User B)
2. User A creates resource (e.g., order ID 100)
3. User B tries to access: GET /api/orders/100
4. If successful → IDOR vulnerability exists

Remediation:

//  VULNERABLE: No authorization check
app.get('/api/orders/:id', authenticate, async (req, res) => {
  const order = await Order.findById(req.params.id)
  res.json(order)  // Returns ANY order if it exists!
})

//  SECURE: Verify ownership
app.get('/api/orders/:id', authenticate, async (req, res) => {
  const order = await Order.findById(req.params.id)

  if (!order) {
    return res.status(404).json({ error: 'Order not found' })
  }

  if (order.userId !== req.user.id && !req.user.isAdmin) {
    return res.status(403).json({ error: 'Forbidden' })
  }
…

API2:2023 - Broken Authentication

Vulnerability: Weak authentication allowing unauthorized access

Common Issues:

• No authentication required
• Weak password requirements
• No rate limiting on login
• Predictable API keys
• JWT with weak secrets
• No token expiration

Example Attack:

# Brute force login (no rate limiting)
for password in $(cat passwords.txt); do
  curl -X POST https://api.example.com/login \
    -d "username=admin&password=$password"
done

Remediation:

//  SECURE: Rate limiting on login
const rateLimit = require('express-rate-limit')

const loginLimiter = rateLimit({
  windowMs: 15 * 60 * 1000, // 15 minutes
  max: 5, // 5 attempts
  message: 'Too many login attempts, please try again later'
})

app.post('/login', loginLimiter, async (req, res) => {
  // Login logic with strong password requirements
  // - Minimum 12 characters
  // - Require uppercase, lowercase, numbers, symbols
  // - Check against common password list
})

API3:2023 - Broken Object Property Level Authorization

Vulnerability: Users can modify properties they shouldn't access

Example Attack (Mass Assignment):

# Normal user update
PATCH /api/users/123
{
  "name": "John Doe",
  "email": "[email protected]"
}

# Attack: Add admin flag
PATCH /api/users/123
{
  "name": "John Doe",
  "email": "[email protected]",
  "isAdmin": true  # ← Attacker tries to elevate privileges!
}