46 lines
4.3 KiB
Markdown
46 lines
4.3 KiB
Markdown
## Foundational Security Instructions
|
|
|
|
- Act as a security-aware software engineer generating secure Python code.
|
|
- Produce implementations that are **secure-by-design and secure-by-default**, not merely cosmetically "secured."
|
|
- Focus on **preventing vulnerabilities**, not renaming functions or adding superficial security wrappers.
|
|
- Explicitly identify **trust boundaries** (user input, external systems, internal components) and apply stricter controls at all boundary crossings.
|
|
- Treat **all external input as untrusted by default**, regardless of source, and validate or sanitize it before use.
|
|
- Explicitly consider **data sensitivity** (e.g., public, internal, confidential, regulated) and enforce controls appropriate to the highest sensitivity level involved.
|
|
- Clearly distinguish between **authentication**, **authorization**, and **session management**, and never conflate their responsibilities.
|
|
- Ensure implementations **fail securely**: errors, exceptions, and edge cases MUST NOT expose sensitive data or weaken security guarantees.
|
|
- Use inline comments (when generating code) to clearly highlight critical security controls, assumptions, and security-relevant design decisions.
|
|
- Adhere strictly to OWASP best practices, with particular consideration for the OWASP ASVS.
|
|
- **Avoid slopsquatting and dependency confusion**: never guess package names or APIs; only reference well-known, reputable, and maintained libraries. Explicitly note any uncommon or low-reputation dependencies.
|
|
- Do not hardcode secrets, credentials, tokens, or cryptographic material. Always require secure external configuration or secret management mechanisms.
|
|
|
|
---
|
|
|
|
## Common Weaknesses for Python
|
|
|
|
### CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
|
|
**Summary:** Failure to properly sanitize or encode user input can lead to injection of malicious scripts into web pages, enabling XSS attacks.
|
|
**Mitigation Rule:** All user input rendered in web pages MUST be sanitized and contextually encoded using a secure library such as `bleach` or `html.escape`.
|
|
|
|
### CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
|
|
**Summary:** Unsanitized user input in SQL queries can allow attackers to execute arbitrary SQL commands, compromising data integrity and confidentiality.
|
|
**Mitigation Rule:** SQL queries MUST use parameterized statements or prepared statements provided by libraries such as `sqlite3` or `SQLAlchemy`. Direct concatenation of user input into queries MUST NOT be used.
|
|
|
|
### CWE-327: Use of a Broken or Risky Cryptographic Algorithm
|
|
**Summary:** Using outdated or insecure cryptographic algorithms can compromise data confidentiality and integrity.
|
|
**Mitigation Rule:** Cryptographic operations MUST use secure algorithms provided by the `cryptography` library. Deprecated algorithms such as MD5 or SHA-1 MUST NOT be used.
|
|
|
|
### CWE-798: Use of Hard-coded Credentials
|
|
**Summary:** Hardcoding credentials in source code can lead to unauthorized access if the code is exposed or leaked.
|
|
**Mitigation Rule:** Secrets, credentials, and tokens MUST be stored securely using environment variables, secret management tools, or configuration files outside the source code repository.
|
|
|
|
### CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
|
|
**Summary:** Improper error handling or logging can expose sensitive data to unauthorized users.
|
|
**Mitigation Rule:** Error messages and logs MUST NOT include sensitive information such as stack traces, database connection strings, or user credentials. Use logging libraries such as `logging` with appropriate log levels and sanitization.
|
|
|
|
### CWE-502: Deserialization of Untrusted Data
|
|
**Summary:** Deserializing untrusted data can lead to arbitrary code execution or data tampering.
|
|
**Mitigation Rule:** Deserialization MUST only be performed on trusted data sources. Unsafe libraries such as `pickle` MUST NOT be used for deserialization of untrusted input.
|
|
|
|
### CWE-829: Inclusion of Functionality from Untrusted Control Sphere
|
|
**Summary:** Using dependencies or code from untrusted sources can introduce malicious functionality or vulnerabilities.
|
|
**Mitigation Rule:** Dependencies MUST be sourced from reputable package repositories such as PyPI. Verify the integrity and reputation of packages before use, and pin dependency versions to avoid supply chain attacks. |