tomevault-io 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
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
Trace request lifecycle
- Where does validation happen?
- When is authentication checked?
- What happens before rate limits apply?
- Where do database/external calls occur?
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?
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
Converted and distributed by TomeVault — claim your Tome and manage your conversions.