secure-coding-standard

<activation_rules>

• NEVER wait for a security review to load this skill. Load it DURING brainstorming, writing-plans, executing-plans, or test-driven-development if the task touches external data or state changes.
• This skill acts as a permanent constraint layer over your standard coding skills. </activation_rules>

<human_confirmation_required> STOP and get explicit user approval before proceeding with any of the following. These are security-boundary changes that cannot be automatically verified:

• Adding new authentication flows or modifying existing auth logic
• Introducing a new category of sensitive data storage (PII, payment info, health data)
• Adding a new external service integration or third-party API
• Modifying CORS configuration or adding new allowed origins
• Introducing new file upload endpoints or handlers
• Changing rate limiting policies or account lockout thresholds
• Granting elevated permissions, new roles, or new admin capabilities </human_confirmation_required>

<execution_workflow> Execute these security constraints strictly. NEVER trust user input. Security overrides all other implementation preferences.

1. THREAT BOUNDARY ANALYSIS (Pre-computation):

   • Identify ALL external inputs (API payloads, URLs, headers, file uploads, query parameters).
   • Identify ALL sensitive data flows (PII, credentials, API keys, financial data).

2. STRICT IMPLEMENTATION CONSTRAINTS (OWASP Mitigation):

   • Injection & Path Traversal: MUST use parameterized queries/ORMs. String concatenation for queries/commands is FORBIDDEN. ALWAYS sanitize file paths and names.
   • XSS & CSRF: MUST encode/sanitize all outputs. MUST enforce anti-CSRF tokens or SameSite cookies for cookie/session-based state-changing actions. For bearer-token mobile/API flows, document why CSRF is not the active threat and verify token validation, CORS, and origin assumptions instead.
   • Access Control & IDOR (BOLA): MUST verify both AuthZ (is admin/user?) AND Ownership (does this user own resource ID X?). Default to 'deny'.
   • SSRF & CORS: NEVER blindly fetch user-supplied URLs; use strict allowlisting. NEVER configure CORS to wildcard * in production.
   • File Uploads: MUST validate strict MIME-types (not just extensions), enforce size limits, and store uploaded files outside the web root.
   • Data & Crypto: NEVER log sensitive data: passwords, JWT, refresh, ID token, FCM token, raw search query text, raw request bodies, SMTP credentials, report descriptions, or any PII. NEVER hardcode secrets. MUST use strong, modern cryptography (e.g., bcrypt/Argon2 for passwords).
   • Abuse Prevention: MUST implement strict rate limiting, throttling, or account lockout mechanisms on sensitive/auth endpoints to prevent brute-force attacks.
   • Business Logic & Concurrency: MUST prevent race conditions (TOCTOU) using database locks (e.g., SELECT FOR UPDATE) or atomic operations on financial/state-changing endpoints.
   • Supply Chain & Headers: NEVER introduce third-party dependencies with known CVEs. MUST configure secure HTTP headers (CSP, HSTS).

3. VALIDATION RULES (Zero Trust):

   • Implement strict type checking and schema validation at the earliest system boundary (e.g., using Zod, Joi, or equivalent).
   • Reject invalid data immediately with safe error codes. Do NOT attempt to "fix" or "guess" malformed payloads.

4. SECURITY VERIFICATION & ADAPTIVE TESTING (CRITICAL):

   • Verify error handling does NOT leak internal stack traces, framework versions, or database structures to the client.
   • TDD EXCEPTION FOR SECURITY: Even if the user explicitly skipped the test-driven-development workflow for this task, if you are modifying AuthZ/AuthN logic, access controls, or critical boundaries, you MUST write an automated failing test attempting to bypass the logic (e.g., "User A attempts to delete User B's profile") to mathematically prove the system is secure.

5. CODE REVIEW PREPARATION:

   • When you are finished and about to invoke requesting-code-review, you MUST explicitly list the security mitigations you implemented in the {DESCRIPTION} parameter so the reviewer can verify them.
   • Classify each security finding using this severity model and structured format: