accelint-security-best-practices（加速安全最佳实践）

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 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

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

1. 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:

Severity Levels:

• Critical: Direct path to data breach, remote code execution, or complete system compromise

- Examples: SQL injection, hardcoded production secrets, no authentication on admin endpoints

• High: Likely to enable unauthorized access, data theft, or service disruption

- Examples: Missing authorization checks, XSS vulnerabilities, insecure session management

• Medium: Could be exploited with specific conditions or chained with other vulnerabilities

- Examples: Missing rate limiting, weak CORS policy, insufficient logging

• Low: Defense-in-depth improvements, best practices, or edge case protections

- Examples: Missing security headers, overly detailed error messages

Quick reference for mapping vulnerabilities:

Load references/quick-reference.md for detailed vulnerability-to-category mapping and anti-pattern detection.

Output: Categorized list of ALL vulnerabilities with their OWASP categories and severity levels. Do not filter or prioritize - list everything found in Phase 1.

Phase 3: Remediate Using Security Patterns

Step 1: Identify your vulnerability category from Phase 2 analysis.

Step 2: Load MANDATORY references for your category. Read each file completely with no range limits.

Notes:

• If vulnerability spans multiple categories, load references for all relevant categories
• Security patterns are cumulative - apply defense in depth by addressing all categories
• Load optional files when implementing specific features (file uploads, MFA, etc.)

Step 3: Scan for quick reference during remediation

Load AGENTS.md to see compressed security rule summaries organized by category. Use as a quick lookup while implementing patterns from the detailed reference files above.

Apply patterns systematically:

1. Load the reference file for the identified vulnerability category
2. Scan the ❌/✅ examples to find matching patterns
3. Apply the security fix ensuring defense in depth
4. Add comments explaining the security consideration and referencing the pattern

Example remediation:

// ❌ Before: SQL Injection vulnerability
const query = `SELECT * FROM users WHERE email = '${email}'`;
const user = await db.query(query);

// ✅ After: Parameterized query prevents injection
// Security: injection-prevention.md - parameterized queries
const user = await db.query(
  'SELECT * FROM users WHERE email = $1',
  [email]
);

Phase 4: Verify Security Fixes

Validate vulnerability closure:

1. Review code to confirm vulnerability is fully addressed
2. Verify no new vulnerabilities introduced by the fix
3. Check defense in depth - are multiple layers protecting critical resources?

Security testing:

1. Run existing test suite - all tests must pass
2. Add security-specific tests for the vulnerability
3. Consider penetration testing for critical vulnerabilities

Document security fix:

// Security fix applied: 2026-02-01
// Vulnerability: SQL injection via email parameter (Critical)
// OWASP Category: A03 - Injection
// Pattern: injection-prevention.md - parameterized queries
// Verified: All tests pass, manual SQL injection attempts blocked

Deciding whether to deploy the fix:

• Critical vulnerabilities: Deploy immediately with emergency process if needed
• High vulnerabilities: Deploy in next release cycle (days, not weeks)
• Medium vulnerabilities: Deploy with next scheduled release
• Low vulnerabilities: Deploy when convenient or batch with other security improvements

If tests fail: Fix the security implementation or find alternative solution. Security fixes should not break functionality.

Common Implementation Pitfalls

Security fixes sometimes conflict with existing functionality. Here are expert solutions for common scenarios:

When Security and Functionality Conflict

Priority order:

1. Never compromise on Critical vulnerabilities (SQL injection, hardcoded secrets, missing auth) - find alternative architecture
2. High vulnerabilities can have slight trade-offs if properly documented and compensated with other controls
3. Medium/Low vulnerabilities may be deferred if business justification is strong and risk is accepted

Documentation requirement for trade-offs:

// SECURITY TRADE-OFF DOCUMENTED: 2026-02-01
// Issue: Rate limiting breaks webhook ingestion from trusted partner
// Decision: Exempt partner IP range from rate limiting
// Compensating controls:
//   - IP whitelist strictly maintained (only 2 partner IPs)
//   - Separate monitoring for partner traffic
//   - Manual review of partner traffic daily
//   - 30-day review scheduled to implement alternative solution
// Risk accepted by: [Name], [Title]

Freedom Calibration

Calibrate guidance specificity to vulnerability severity:

The test: "What's the severity and blast radius?"

• Critical/High severity → Low freedom with exact patterns to prevent mistakes
• Medium severity → Medium freedom with validated approaches
• Low severity → High freedom with general best practices

Important Notes

• Audit everything philosophy - Audit ALL code for security vulnerabilities. Internal utilities, helpers, and data transformations are frequently exposed through APIs or user interactions even when they appear isolated. Do not make assumptions about security boundaries.
• Report all findings - Perform systematic static analysis to identify and report ALL vulnerabilities with their severity and OWASP category. Do not filter based on "likelihood" of exploitation.
• Reference files are authoritative - The patterns in references/ follow OWASP best practices. Follow them exactly unless security requirements dictate otherwise.
• Defense in depth - Layer security controls so single vulnerability doesn't compromise entire system. Authentication + authorization + input validation + rate limiting.
• Security testing - Security fixes require testing with malicious inputs and edge cases. Add tests for attack scenarios before deploying.
• Incident response - Security logging and monitoring enable detection and response to attacks. Log all security events with sufficient detail for investigation.

Quick Decision Tree

Use this table to rapidly identify which security category applies and appropriate severity.

Audit everything: Identify ALL security vulnerabilities in the code regardless of current exposure. Report all findings with severity and OWASP category.

How to use this table:

1. Identify the pattern from code review
2. Find matching row in "If You See..." column
3. Note the OWASP Category and Typical Severity
4. Jump to corresponding Security Category in Phase 3
5. Load MANDATORY reference files for that category