Add/update Python_Flask_rules.mdc security rules

Author: justin-pagano-klv

.cursor/rules/Python_Flask_rules.mdc

@@ -0,0 +1,46 @@
+---
+description: This rule enforces security best practices for Python applications built with Flask, focusing on preventing common web vulnerabilities.
+globs: **/*.py
+alwaysApply: false
+---
+
+# Secure Python/Flask Application Development Rules
+
+- As a security-aware developer, generate secure Python code using Flask 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.
+- **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.
+
+## Memory Safety Considerations
+Python is a memory-safe language due to its automatic memory management (garbage collection) and abstraction of memory access. Therefore, explicit memory safety considerations, such as buffer overflows or use-after-free vulnerabilities, are not directly applicable at the application code level when writing Python.
+
+## Top CWEs for Python + Flask
+
+### CWE-79: Cross-Site Scripting (XSS)
+**Summary:** XSS occurs when an application includes untrusted data in an HTML page without proper validation or escaping, allowing attackers to execute scripts in the victim's browser.
+**Mitigation Rule:** Always use Flask's Jinja2 templating engine, which performs automatic HTML escaping by default. If rendering content directly outside of Jinja2 or explicitly marking content as safe, ensure all user-supplied or untrusted data is rigorously validated and properly HTML-escaped using `jinja2.escape()` or `werkzeug.utils.escape()`. Avoid using `|safe` or `autoescape off` in Jinja2 unless strictly necessary and after thorough validation and justification.
+
+### CWE-89: SQL Injection
+**Summary:** SQL Injection allows attackers to manipulate SQL queries by providing malicious input, potentially leading to unauthorized data access or modification.
+**Mitigation Rule:** Never concatenate user input directly into SQL queries. Always use parameterized queries or Prepared Statements via an Object-Relational Mapper (ORM) like SQLAlchemy or directly through database drivers that support parameterization.
+
+### CWE-20: Improper Input Validation
+**Summary:** Improper input validation occurs when an application fails to properly validate, filter, or sanitize user-supplied input before processing it.
+**Mitigation Rule:** Implement strict server-side validation for all user inputs against expected data types, formats, lengths, and ranges. Use libraries such as `WTForms` or `Pydantic` for comprehensive schema validation and explicit rejection of invalid input. Do not rely solely on client-side validation.
+
+### CWE-22: Path Traversal
+**Summary:** Path Traversal allows attackers to access arbitrary files and directories on the server by manipulating file paths, often by using "dot-dot-slash" (../) sequences.
+**Mitigation Rule:** Never construct file paths using unvalidated user input. When dealing with file operations or serving static content, use `werkzeug.utils.safe_join()` to securely combine path components and restrict access to designated directories, ensuring paths cannot traverse outside the intended base directory.
+
+### CWE-352: Cross-Site Request Forgery (CSRF)
+**Summary:** CSRF forces an authenticated user to submit a malicious request to a web application without their explicit consent.
+**Mitigation Rule:** Implement robust CSRF protection for all state-changing operations (e.g., POST, PUT, DELETE requests). Use Flask-WTF or Flask-Security-Too to generate and validate CSRF tokens, ensuring each form submission or AJAX request includes a valid, unique token that is checked on the server-side.
+
+### CWE-287: Improper Authentication
+**Summary:** Improper authentication allows attackers to bypass or compromise authentication mechanisms, gaining unauthorized access.
+**Mitigation Rule:** Implement strong and secure authentication mechanisms using established libraries like Flask-Login or Flask-Security-Too. Always hash passwords using strong, adaptive, and modern hashing algorithms (e.g., bcrypt) via `werkzeug.security.generate_password_hash()` and `check_password_hash()`. Do not store plain-text passwords or use weak hashing functions. Enforce secure session management, such as setting `session.permanent = True` only for appropriate use cases and ensuring `session.secret_key` is strong and securely managed.
+
+### CWE-798: Use of Hard-coded Credentials
+**Summary:** Hard-coding credentials or secrets directly within the source code makes them easily discoverable and compromises security.
+**Mitigation Rule:** Never hard-code sensitive information such as API keys, database credentials, secret keys, or cryptographic keys directly in the source code. Store all secrets and sensitive configuration externally using environment variables (accessible via `os.environ`), dedicated configuration files loaded securely (e.g., `.env` files with `python-dotenv`), or a secure secret management service.