Security Review

A read-only security review skill focused on application-level security concerns that emerge after deployment—issues that framework security guides don't cover.

Philosophy

Framework security checklists help teams use tools correctly. They stop where application-specific behavior begins. This skill focuses on what breaks later:

• •Abuse and misuse that looks like valid traffic
• •Business logic that works for real users but fails at scale
• •APIs called in ways you didn't expect
• •Automated traffic exploiting assumptions about human behavior

Review Checklist

When reviewing code, systematically evaluate these areas:

1. Automated Traffic & Bot Resilience

Key questions:

• •Can we distinguish human traffic from automated traffic?
• •Which endpoints are most attractive to bots?
• •Would IP blocking alone be sufficient, or is behavioral analysis needed?

Look for:

• •Endpoints with no bot detection or CAPTCHA
• •Scraping-attractive routes (pricing, product data, user directories)
• •Form submissions without behavioral signals
• •Login/signup flows vulnerable to credential stuffing

Red flags:

- Public APIs without authentication
- No rate limiting on enumerable resources (/users/1, /users/2, ...)
- Predictable resource identifiers
- Missing bot detection on high-value flows

2. API Protection & Rate Limiting

Key questions:

• •Are rate limits applied per user, per token, or per IP?
• •Do authenticated and anonymous users have different limits?
• •Can expensive operations be triggered repeatedly?
• •Do limits reflect actual usage patterns?

Look for:

• •Missing rate limiting on mutation endpoints
• •Rate limits that don't account for authenticated vs anonymous
• •Expensive operations (DB queries, external API calls, file processing) without throttling
• •Generic rate limits that don't match business logic

Red flags:

- Global rate limits only (no per-user/per-endpoint granularity)
- Rate limits checked after expensive operations
- No rate limiting on password reset, signup, or verification flows
- Missing rate limits on search or export endpoints

Good patterns:

// Rate limit with user context
rateLimit({
  keyGenerator: (req) => req.user?.id || req.ip,
  windowMs: 15 * 60 * 1000,
  max: (req) => req.user ? 1000 : 100, // Different limits for authed users
});

// Tiered limits for different operations
const limits = {
  read: { window: '1m', max: 100 },
  write: { window: '1m', max: 10 },
  export: { window: '1h', max: 5 },
};

3. Business Logic Abuse

Key questions:

• •What actions would be expensive or harmful if automated?
• •Which flows could be abused without triggering errors?
• •Where do product rules need enforcement beyond validation?

Look for:

• •Signup flows assuming humans move slowly
• •Free trials assuming honest usage
• •Checkout logic assuming single user at a time
• •Referral/reward systems without abuse prevention
• •Resource creation without ownership limits

Red flags:

- No limit on free trial signups per email domain
- Coupon/discount codes without usage tracking
- Referral bonuses without fraud detection
- Bulk operations without progress limits
- Vote/rating systems without velocity checks

Abuse scenarios to consider:

• •Can a user create unlimited resources?
• •Can timing attacks reveal sensitive information?
• •Can parallel requests bypass sequential assumptions?
• •Can free tiers be exploited for resource mining?

4. Input Validation & Early Rejection

Key questions:

• •Do bad requests reach expensive code paths?
• •Are invalid requests rejected as early as possible?
• •Do failures behave predictably under load?

Look for:

• •Validation after database queries or external API calls
• •Large payload processing before authentication
• •Missing size limits on uploads, JSON bodies, arrays
• •Regex patterns vulnerable to ReDoS
• •Deep object nesting without limits

Red flags:

- No Content-Length limits
- Unbounded array iteration from user input
- Database queries before input validation
- File processing before permission checks
- JSON parsing of arbitrary-depth objects

Good patterns:

// Reject early - before any expensive work
app.use(express.json({ limit: '100kb' }));

// Validate structure before processing
const schema = z.object({
  items: z.array(z.string()).max(100),
  depth: z.number().max(10),
});

// Fail fast on invalid input
if (!isValidFormat(input)) {
  return res.status(400).send('Invalid format');
}
// Only then do expensive work
const result = await expensiveOperation(input);

5. Cost & Resource Protection

Key questions:

• •What's the cost multiplier of a single request? (1 request = N database queries?)
• •Can users trigger unbounded resource consumption?
• •Are serverless/usage-based costs protected?

Look for:

• •N+1 query patterns triggered by user input
• •Unbounded pagination or export
• •Large file uploads without quotas
• •External API calls multiplied by user input
• •Cache-busting through parameter manipulation

Red flags:

- No pagination limits (page_size=10000)
- Export endpoints without row limits
- Image processing without size limits
- GraphQL without query depth/complexity limits
- Recursive operations on user-provided data

6. Monitoring & Observability

Key questions:

• •Can we detect when abuse starts?
• •Do we know which endpoints are being targeted?
• •Are security events logged and alertable?

Look for:

• •Missing logging on authentication failures
• •No metrics on rate limit triggers
• •Unlogged admin/sensitive operations
• •No anomaly detection signals

Should be logged:

- Failed authentication attempts (with IP, user agent)
- Rate limit triggers
- Permission denied events
- Unusual access patterns (bulk reads, rapid requests)
- Admin actions

Review Process

1. •

   Map the attack surface

   • •List all public endpoints
   • •Identify authenticated vs unauthenticated routes
   • •Find endpoints that accept user input
   • •Note endpoints that trigger expensive operations
2. •

   Trace request lifecycle

   • •Where does validation happen?
   • •When is authentication checked?
   • •What happens before rate limits apply?
   • •Where do database/external calls occur?
3. •

   Think like an abuser

   • •What if this endpoint was called 10,000 times?
   • •What if multiple requests came simultaneously?
   • •What if the input was at maximum allowed size?
   • •What if a bot was probing this systematically?
4. •

   Check deployment context

   • •Serverless? (cost implications of abuse)
   • •Edge? (different security model)
   • •Traditional server? (resource exhaustion risks)

Output Format

When reporting findings, use this structure:

## Security Review: [Component/Feature Name]

### Summary
[Brief overview of what was reviewed and key findings]

### Critical Issues
[Issues that need immediate attention]

### Warnings
[Issues that should be addressed but aren't immediately exploitable]

### Recommendations
[Suggested improvements and patterns to adopt]

### Questions for the Team
[Areas that need clarification or business context]

What This Skill Does NOT Cover

This skill focuses on application-layer abuse. It does not replace:

• •Framework-specific security guides (follow those first)
• •OWASP Top 10 basics (XSS, SQLi, CSRF)
• •Infrastructure security (TLS, secrets management)
• •Authentication implementation details
• •Dependency vulnerability scanning

For those concerns, use framework documentation and dedicated security tools.

References

• •OWASP API Security Top 10
• •Rate limiting best practices
• •Bot management strategies
• •Serverless security considerations