accelint-security-best-practices

What this skill does

# Security Best Practices

Systematic security auditing and vulnerability detection for JavaScript/TypeScript applications. Combines audit workflow with OWASP Top 10 security patterns for production-ready code.

**Framework-Agnostic Guidance**: This skill provides security principles applicable across frameworks (Express, Fastify, Nest.js, Next.js, etc.). Code examples illustrate concepts using common patterns—adapt them to your project's specific framework and package manager (npm, yarn, pnpm, bun).

## NEVER Do When Implementing Security

**Note:** For general best practices (type safety, code quality, documentation), use the respective accelint skills. This section focuses exclusively on security-specific anti-patterns.

- **NEVER hardcode secrets** - API keys, tokens, passwords, or credentials in source code are immediately compromised when pushed to version control. Even private repositories leak secrets through employee turnover, third-party access, and git history. In 2024 breach analysis, 47% of exposed credentials came from `.env` files accidentally committed then 'deleted' (but preserved in git history). Attackers scan public GitHub commits within minutes of push. Use environment variables exclusively.

- **NEVER trust user input** - Validate with schemas (Zod, Joi) covering type, format, size, and content.

- **NEVER concatenate user input into queries** - Use parameterized queries, ORMs, or prepared statements exclusively. String concatenation in SQL, NoSQL, or shell commands enables injection attacks.

- **NEVER store sensitive data in localStorage** - localStorage is vulnerable to XSS attacks where malicious scripts steal tokens. JWT tokens, session IDs, or credentials in localStorage persist across sessions and are accessible to any JavaScript code. Use httpOnly cookies for auth tokens.

- **NEVER skip authorization checks** - Authentication verifies identity; authorization verifies permission. Attackers will manipulate IDs, skip authentication, or guess URLs. Every endpoint accessing resources must verify the requesting user owns that resource or has appropriate role.

- **NEVER expose detailed errors to users** - Log server-side, return generic messages. Stack traces leak architecture for reconnaissance.

- **NEVER use Array.includes() for permission checks** - Permission arrays with 100+ roles suffer O(n) lookup time and type safety issues. Use `Set.has()` for O(1) lookup or role-based access control (RBAC) with proper type checking.

- **NEVER skip rate limiting on APIs** - Unlimited API requests enable brute force attacks (1000 password attempts/second), denial of service (exhaust server resources), or data scraping (enumerate all users/resources). Apply rate limits to all endpoints, with stricter limits on authentication and expensive operations.

- **NEVER log sensitive data** - Passwords, tokens, credit cards, or personal information in logs persist in log aggregation systems, backups, and third-party services. Logs are accessible to more people than the application itself. Redact sensitive fields before logging.

- **NEVER use default configurations in production** - Default secrets, disabled security headers, permissive CORS, or development modes in production create known vulnerabilities. Attackers scan for defaults. Harden all configurations for production environments.

## Before Implementing Security, Ask

Apply these tests to ensure comprehensive security coverage:

### Threat Assessment
- **What's the attack surface?** Identify all points where user input enters the system (forms, APIs, file uploads, URLs)
- **What's the worst-case scenario?** Consider data breaches, unauthorized access, service disruption, or financial loss
- **Who are the attackers?** Script kiddies exploit known vulnerabilities; sophisticated attackers chain multiple weaknesses

### Compliance Verification
- **Do I have authentication on all protected routes?** Public APIs may be intentional, but verify each endpoint's access policy
- **Are authorization checks before operations?** Verify ownership/permissions before reading, writing, or deleting resources
- **Is all user input validated?** Check type, format, size, and content with schemas before processing

### Defense in Depth
- **Is there a single point of failure?** Layer defenses so one bypass doesn't compromise entire system
- **Are errors handled gracefully?** Unhandled errors leak information; proper handling maintains security posture
- **Is logging sufficient for audit trails?** Security events (login attempts, access denials, suspicious patterns) must be logged for incident response

## How to Use

This skill uses **progressive disclosure** to minimize context usage:

### 1. Start with the Workflow (SKILL.md)
Follow the 4-phase audit workflow below for systematic security analysis.

### 2. Reference Security Rules Overview (AGENTS.md)
Load [AGENTS.md](AGENTS.md) to scan compressed security rule summaries organized by category.

### 3. Load Specific Security Patterns as Needed
When you identify specific security issues, load corresponding reference files for detailed ❌/✅ examples.

### 4. Use the Report Template
When this skill is invoked, use the standardized report format:

**Template:** [`assets/output-report-template.md`](assets/output-report-template.md)

## Security Audit Workflow

**Two modes of operation:**

1. **Audit Mode** - Skill invoked directly (`/accelint-security-best-practices <path>`) or user explicitly requests security audit
   - Generate a structured audit report using the template (Phases 1-2 only)
   - Report findings for user review before implementation
   - User decides which security fixes to apply

2. **Implementation Mode** - Skill triggers automatically during feature work
   - Identify and apply security fixes directly (all 4 phases)
   - No formal report needed
   - Focus on fixing vulnerabilities inline

**Copy this checklist to track progress:**

```
- [ ] Phase 1: Discover - Identify security vulnerabilities through systematic code analysis
- [ ] Phase 2: Categorize - Classify issues by OWASP category and severity
- [ ] Phase 3: Remediate - Apply security patterns from references/
- [ ] Phase 4: Verify - Validate fixes and confirm vulnerability closure
```

### Phase 1: Discover Security Vulnerabilities

**CRITICAL: Audit ALL code for security vulnerabilities.** Do not skip code based on assumptions about exposure. Internal utilities, helpers, and data transformations are frequently exposed through APIs, file uploads, or user interactions even if their implementation appears isolated.

**Perform systematic static code analysis to identify ALL security anti-patterns:**
- Hardcoded secrets (API keys, passwords, tokens)
- Missing input validation (user data, file uploads, API responses)
- Injection vulnerabilities (SQL, NoSQL, Command, XSS)
- Broken access control (missing auth, no ownership checks, IDOR)
- Insecure authentication (tokens in localStorage, weak session management)
- Missing rate limiting (auth endpoints, expensive operations)
- Sensitive data exposure (logs, error messages, client responses)
- Security misconfiguration (default configs, missing headers, permissive CORS)
- Vulnerable dependencies (outdated packages, known CVEs)
- Missing CSRF protection (state-changing operations)
- SSRF vulnerabilities (unvalidated URL fetching)

**Output**: Complete list of ALL identified vulnerabilities with their locations, severity, and OWASP category. Do not filter based on "likelihood" - report everything found.

### Phase 2: Categorize and Assess Risk

For EVERY vulnerability identified in Phase 1, categorize by OWASP category and severity:

**Categorize ALL vulnerabilities by OWASP Top 10 category:**

| OWASP Category | Common Issues | Severity Range |
|----------------|---------------|----------------|
| A01: Broken Access Control | Missing auth, no ownership checks, IDOR | Critical-High |
| A02: Cryptographic Failures | Hardcoded secrets, weak ha