|
| 1 | +--- |
| 2 | +description: Generates secure JavaScript code for React applications, focusing on preventing common vulnerabilities like XSS, CSRF, and hardcoded secrets, adhering to OWASP ASVS guidelines. |
| 3 | +globs: **/*.js, **/*.ts |
| 4 | +alwaysApply: false |
| 5 | +--- |
| 6 | +# Security-First Code Generation Guidelines for JavaScript/React |
| 7 | + |
| 8 | +As a security-aware developer, generate secure JavaScript code using React that inherently prevents top security weaknesses. Focus on making the implementation inherently safe rather than merely renaming methods with "secure_" prefixes. Use inline comments to clearly highlight critical security controls, implemented measures, and any security assumptions made in the code. Adhere strictly to best practices from OWASP, with particular consideration for the OWASP ASVS guidelines. |
| 9 | + |
| 10 | +**Avoid Slopsquatting**: Be careful when referencing or importing packages. Do not guess if a package exists. Comment on any low reputation or uncommon packages you have included. |
| 11 | + |
| 12 | +## General Security Considerations |
| 13 | + |
| 14 | +* **Memory Safety**: JavaScript is a garbage-collected, memory-safe language. Focus on preventing logical vulnerabilities rather than low-level memory errors. |
| 15 | +* **Defense-in-Depth**: Implement security controls at multiple layers (frontend, backend, network) to provide comprehensive protection. |
| 16 | +* **Least Privilege**: Design components and user roles with the minimum necessary permissions to perform their functions. |
| 17 | +* **Secure by Default**: Choose libraries, frameworks, and configurations that prioritize security and safe defaults. |
| 18 | + |
| 19 | +## Top CWEs and Mitigation Rules for JavaScript/React |
| 20 | + |
| 21 | +### CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') (XSS) |
| 22 | +**Summary:** Allows attackers to inject client-side scripts into web pages viewed by other users, leading to defacement, session hijacking, or data theft. |
| 23 | +**Mitigation Rule:** Always leverage React's automatic escaping for dynamic content. Strictly avoid `dangerouslySetInnerHTML` unless absolutely necessary; if used, ensure all user-supplied HTML is thoroughly sanitized on the server-side or by a robust client-side library like `dompurify` before rendering. |
| 24 | + |
| 25 | +### CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') |
| 26 | +**Summary:** Allows an attacker to access, modify, or create arbitrary files and directories on the server or in local storage by manipulating file paths. |
| 27 | +**Mitigation Rule:** For any operations involving file paths, URLs, or resource identifiers derived from untrusted input (e.g., user input, URL parameters), validate and sanitize inputs rigorously. Prefer using allow-lists for valid path components or resource names, and never directly concatenate untrusted input into file system paths or dynamic imports. |
| 28 | + |
| 29 | +### CWE-352: Cross-Site Request Forgery (CSRF) |
| 30 | +**Summary:** Allows an attacker to trick a victim into submitting an unintended request to a web application, performing actions on the victim's behalf. |
| 31 | +**Mitigation Rule:** For all state-changing operations (POST, PUT, DELETE, etc.), ensure server-side CSRF protection is in place, typically via unique, per-session CSRF tokens, which the React application must include in its requests. Additionally, configure `SameSite` cookies (e.g., `Lax` or `Strict`) and validate `Origin` and `Referer` headers on the server for enhanced protection. |
| 32 | + |
| 33 | +### CWE-20: Improper Input Validation |
| 34 | +**Summary:** Failure to validate input can lead to various vulnerabilities including injection, data corruption, and logic flaws, by accepting malicious or malformed data. |
| 35 | +**Mitigation Rule:** Implement comprehensive input validation on both the client-side (for user experience) and, critically, on the server-side (for security enforcement). Use strict allow-lists for expected data types, formats, lengths, and ranges. Never trust client-side validation alone. |
| 36 | + |
| 37 | +### CWE-306: Missing Authentication for Critical Function |
| 38 | +**Summary:** Critical functions lack proper authentication mechanisms, allowing unauthorized users to access sensitive operations or data. |
| 39 | +**Mitigation Rule:** Ensure all sensitive client-side actions (e.g., API calls modifying user data, administrative functions) are explicitly backed by robust server-side authentication and authorization checks. Frontend UI elements for sensitive actions should only be rendered or enabled if the user is authenticated and authorized, but this must never be the sole control. |
| 40 | + |
| 41 | +### CWE-502: Deserialization of Untrusted Data |
| 42 | +**Summary:** Deserializing untrusted or malformed data can lead to remote code execution, denial of service, or arbitrary file creation due to insecure object reconstruction. |
| 43 | +**Mitigation Rule:** Avoid deserializing untrusted data directly from user input or external sources within the React application or any associated backend services it interacts with. If deserialization is unavoidable, use secure, restricted serialization formats (e.g., JSON with schema validation, not arbitrary object graphs) and ensure strict validation of the deserialized data. |
| 44 | + |
| 45 | +### CWE-798: Use of Hard-coded Credentials |
| 46 | +**Summary:** Storing sensitive information like API keys, database passwords, or secret keys directly within source code can lead to unauthorized access and compromise. |
| 47 | +**Mitigation Rule:** Absolutely never hardcode any secrets, API keys, credentials, or sensitive configuration values directly into the JavaScript/React source code or public build artifacts. Utilize environment variables (e.g., `process.env.REACT_APP_MY_SECRET`), secure configuration management systems, or proxy sensitive API calls through a secure backend service to protect credentials. |
0 commit comments