@sun-asterisk/sunlint 1.3.36 → 1.3.38

package/origin-rules/security-en.md

@@ -3,33 +3,46 @@
 > This is a comprehensive list of security rules designed to enhance the security posture of applications.
 > Each rule includes a title, detailed description, applicable programming languages, and priority level.
 
-### 📘 Rule S001 – Fail securely when access control errors occur
+### 📘 Rule S001 – Authenticate backend component communications securely
 
-- **Objective**: Ensure the system does not accidentally grant access when errors occur, helping to reduce the risk of unauthorized access and protect sensitive resources.
+- **Objective**: Ensure all communications between backend components (APIs, middleware, data layers) are authenticated using secure, short-lived credentials instead of static secrets.
 - **Details**:
-  - When errors occur in access control checks (e.g., query errors, runtime exceptions), the system must deny access instead of granting default permissions.
-  - Must not fall back to "allow" state if permission data is missing or logic errors occur.
-  - Access control mechanisms must fail in a "deny by default" manner.
+  - Backend-to-backend communications that bypass standard user session mechanisms must be authenticated.
+  - **Required authentication methods**:
+    - Individual service accounts (per-service identity)
+    - Short-term tokens (JWT with short expiry, OAuth tokens)
+    - Certificate-based authentication (mTLS)
+  - **Prohibited credentials**:
+    - Static passwords or API keys
+    - Shared accounts with privileged access
+    - Long-lived unchanging credentials
+  - Apply to: service-to-service calls, internal APIs, message queues, database connections, cache layers.
 - **Applies to**: All languages
-- **Tools**: SonarQube (S4524), PMD (SecurityCodeGuidelines), Manual Review, Unit Test
+- **Tools**: Manual Review, IAM Policy Audit, mTLS Scanner, Secret Rotation Checker
 - **Principles**: CODE_QUALITY, SECURITY
-- **Version**: 1.1
-- **Status**: draft
+- **Version**: 2.0
+- **Status**: activated
 - **Severity**: critical
 
-### 📘 Rule S002 – Avoid IDOR vulnerabilities in CRUD operations
+### 📘 Rule S002 – Protect against OS command injection
 
-- **Objective**: Prevent unauthorized access to sensitive data by verifying users' actual access rights, avoiding reliance solely on IDs in URLs.
+- **Objective**: Prevent OS command injection attacks by ensuring all operating system calls use parameterized queries or proper output encoding.
 - **Details**:
-  - Must not control permissions based solely on `id` sent from the client.
-  - Always verify resource ownership at the backend (authorization logic).
-  - Prefer using UUID or encrypted IDs to avoid predictable sequential IDs.
-  - Check APIs like: `GET/PUT/DELETE /api/resource/{id}` must ensure the id belongs to the current user.
+  - **Never** concatenate user input directly into OS commands or shell executions.
+  - **Required protection methods**:
+    - Use parameterized OS queries (subprocess with argument lists)
+    - Apply contextual command line output encoding
+    - Use language-specific safe APIs (e.g., `subprocess.run()` with `shell=False`)
+  - **Avoid**:
+    - `shell=True` with user input
+    - String concatenation in `exec()`, `system()`, `Runtime.exec()`
+    - Backtick operators or `$()` with untrusted data
+  - Validate and sanitize all inputs before passing to system commands.
 - **Applies to**: All languages
-- **Tools**: SonarQube (S6142, S2076), Semgrep (custom rule), Manual Review
+- **Tools**: SonarQube (S2076, S4721), Semgrep (command-injection), Bandit (B602, B603), Manual Review
 - **Principles**: CODE_QUALITY, SECURITY
-- **Version**: 1.1
-- **Status**: draft
+- **Version**: 2.0
+- **Status**: activated
 - **Severity**: critical
 
 ### 📘 Rule S003 – URL redirects must be within an allow list
@@ -63,81 +76,109 @@
 - **Status**: activated
 - **Severity**: medium
 
-### 📘 Rule S005 – Do not use Origin header for authentication or access control
+### 📘 Rule S005 – Enforce authorization at trusted service layer
 
-- **Objective**: Prevent authentication or authorization decisions based on `Origin` header – which can be easily spoofed from the client side and is unreliable for security purposes.
+- **Objective**: Ensure authorization rules are enforced at a trusted server-side service layer, not relying on client-side controls that can be manipulated.
 - **Details**:
-  - `Origin` header can be modified from the client side (via curl, script, proxy), so it must not be used as a basis for:
-    - User identification
-    - Access permission checks
-    - Security business logic routing
-  - `Origin` should only be used for source authentication in CSRF checks or CORS policies, **not for authorization decisions**.
-  - If behavior needs to be limited by domain, must check against tokens, user sessions, or actually verified scopes.
+  - **Never** rely on client-side JavaScript for authorization decisions.
+  - **Required practices**:
+    - Enforce all authorization checks on trusted backend services
+    - Validate permissions server-side before processing requests
+    - Use middleware or interceptors at the service layer
+  - **Untrusted controls to avoid**:
+    - Client-side JavaScript permission checks
+    - Hidden form fields for authorization
+    - URL parameters for access control
+    - Browser-stored tokens without server validation
+  - All sensitive operations must be re-validated at the backend regardless of client-side checks.
 - **Applies to**: All languages
-- **Tools**: Manual Review, Semgrep (custom rule), SonarQube (custom rule)
+- **Tools**: Manual Review, Static Analysis, Penetration Testing, SonarQube (custom rule)
 - **Principles**: CODE_QUALITY, SECURITY
-- **Version**: 1.0
+- **Version**: 2.0
 - **Status**: activated
-- **Severity**: low
+- **Severity**: critical
 
-### 📘 Rule S006 – Do not send recovery or activation codes in plaintext
+### 📘 Rule S006 – Do not use default credentials for service authentication
 
-- **Objective**: Prevent leakage of verification codes, recovery codes, or activation tokens if email/SMS is intercepted or exposed – thereby minimizing the risk of account takeover attacks.
+- **Objective**: Ensure service authentication never uses default or well-known credentials that attackers can easily guess or find in documentation.
 - **Details**:
-  - Should not send recovery or activation codes in predictable formats, sequential numbers, or containing user identifying information.
-  - Codes sent via email/SMS must be random codes with short time-to-live (TTL), verified one-way by the system (hashed) or verified by session.
-  - Should not store plaintext codes in database or log sent code content.
-  - Prefer verification via temporary encrypted one-time links.
+  - **Never** use default credentials for any service authentication:
+    - `root/root`, `admin/admin`, `test/test`
+    - Default database passwords (e.g., `postgres/postgres`, `sa/sa`)
+    - Factory-default API keys or tokens
+  - **Required practices**:
+    - Generate unique, strong credentials for each service instance
+    - Rotate credentials regularly
+    - Use secrets management tools (Vault, AWS Secrets Manager)
+  - Scan configurations and deployment scripts for default credential patterns.
+  - Block deployments containing default credentials in CI/CD pipelines.
 - **Applies to**: All languages
-- **Tools**: Manual Review, Semgrep (custom rule), Secret Detection (regex scanner), SonarQube (custom rule)
+- **Tools**: Manual Review, Secret Scanner, GitLeaks, TruffleHog, CI/CD Policy Checks
 - **Principles**: CODE_QUALITY, SECURITY
-- **Version**: 1.0
+- **Version**: 2.0
 - **Status**: activated
-- **Severity**: medium
+- **Severity**: critical
 
-### 📘 Rule S007 – Do not store OTP codes in plaintext
+### 📘 Rule S007 – Perform output encoding before interpreter use
 
-- **Objective**: Protect the system from OTP reuse attacks if database/logs are accessed without authorization. OTP, magic-links, or reset codes must be treated like passwords – only stored in one-way hashed form, not recoverable.
+- **Objective**: Ensure the application performs proper output encoding and escaping as a final step before data is used by the target interpreter, preventing injection attacks.
 - **Details**:
-  - Must not store OTP codes, reset tokens, or magic-link codes in original form (plaintext) in database or log files.
-  - OTP should have short TTL (e.g., 5 minutes) and be stored using hash functions like SHA-256.
-  - During verification, should only compare hashed versions.
-  - Never resend original OTP to user if already stored – generate new code if needed.
+  - Output encoding must occur either:
+    - As a final step before being used by the interpreter
+    - Or by the interpreter itself (using built-in encoding features)
+  - **Context-specific encoding**:
+    - HTML context: encode `<`, `>`, `&`, `"`, `'`
+    - JavaScript context: escape strings properly
+    - SQL context: use parameterized queries
+    - URL context: use `encodeURIComponent()`
+    - Shell context: escape shell metacharacters
+  - **Never** trust that earlier encoding is sufficient – encode at the point of use.
+  - Use framework-provided encoding functions where available.
 - **Applies to**: All languages
-- **Tools**: Manual Review, Semgrep (custom rule), Secret Detection, SonarQube (custom rule)
+- **Tools**: SonarQube (S5131, S2076), Semgrep (injection rules), ESLint, Manual Review
 - **Principles**: CODE_QUALITY, SECURITY
-- **Version**: 1.0
+- **Version**: 2.0
 - **Status**: activated
-- **Severity**: medium
+- **Severity**: high
 
-### 📘 Rule S008 – Encryption algorithms and parameters must support flexible configuration and upgrades (crypto agility)
+### 📘 Rule S008 – Validate and sanitize SVG content
 
-- **Objective**: Avoid binding the system to outdated cryptographic algorithms or parameters (like MD5, SHA-1, DES...), ensuring easy upgrades when standards change or new vulnerabilities emerge.
+- **Objective**: Ensure user-supplied SVG (Scalable Vector Graphics) content is validated or sanitized to prevent script injection and other attacks.
 - **Details**:
-  - Do not hardcode algorithms or encryption modes in source code.
-  - Components like encryption algorithms, key size, hash rounds, cipher modes... should be configured via files or environment variables.
-  - Prefer using modern algorithms like AES-GCM, SHA-256, Argon2, ChaCha20.
-  - Algorithm changes should not require modifying core logic in code.
+  - SVG files can contain embedded scripts and potentially dangerous elements.
+  - **Allowed elements** (safe for graphics):
+    - Drawing elements: `svg`, `path`, `rect`, `circle`, `ellipse`, `line`, `polyline`, `polygon`
+    - Grouping: `g`, `defs`, `use`, `symbol`
+    - Styling: `style` (with restrictions), `linearGradient`, `radialGradient`
+  - **Prohibited elements** (must be removed/rejected):
+    - `script` tags
+    - `foreignObject` (can embed arbitrary HTML)
+    - Event handlers (`onclick`, `onload`, `onerror`, etc.)
+    - External references (`xlink:href` to external URLs)
+  - Use SVG sanitization libraries (e.g., DOMPurify with SVG profile).
+  - Consider converting SVGs to raster images for untrusted sources.
 - **Applies to**: All languages
-- **Tools**: Manual Review, Semgrep (custom rule), Secret Scanners, SonarQube (custom rule)
-- **Principles**: CODE_QUALITY, MAINTAINABILITY, SECURITY
-- **Version**: 1.1
-- **Status**: draft
-- **Severity**: low
+- **Tools**: DOMPurify, svg-sanitizer, Manual Review, CSP Headers
+- **Principles**: CODE_QUALITY, SECURITY
+- **Version**: 2.0
+- **Status**: activated
+- **Severity**: high
 
-### 📘 Rule S009 – Do not use insecure encryption modes, padding, or cryptographic algorithms
+### 📘 Rule S009 – Use only approved cryptographic algorithms, modes, and hash functions
 
-- **Objective**: Prevent security vulnerabilities from using outdated encryption or hash algorithms, insecure padding/encryption modes leading to data exposure, pattern leakage, or padding oracle attacks.
+- **Objective**: Prevent cryptographic vulnerabilities by ensuring only secure block modes, padding schemes, ciphers, and hash functions are used throughout the application.
 - **Details**:
-  - Do not use ECB mode in symmetric encryption (AES/3DES/Blowfish), as it reveals identical data patterns.
-  - Avoid insecure padding like `PKCS#1 v1.5` in RSA, vulnerable to padding oracle attacks.
-  - Do not use encryption algorithms with block size < 128-bit like `Triple-DES`, `Blowfish`, vulnerable to brute-force and collision attacks.
-  - Do not use weak hash functions that have been broken like `MD5`, `SHA-1`.
-  - In cases requiring backward compatibility (legacy), must isolate and clearly warn.
+  - Do not use insecure block modes (e.g., ECB) as they reveal identical data patterns and are vulnerable to pattern analysis attacks.
+  - Do not use weak padding schemes (e.g., `PKCS#1 v1.5`) which are vulnerable to padding oracle attacks.
+  - Use only approved ciphers and modes such as `AES` with `GCM` (Galois/Counter Mode) for authenticated encryption.
+  - Use only approved hash functions for general cryptographic use cases, including digital signatures, HMAC, KDF, and random bit generation.
+  - Disallowed hash functions such as `MD5` must not be used for any cryptographic purpose, including checksums, integrity verification, or password hashing.
+  - Do not use encryption algorithms with block size < 128-bit like `Triple-DES`, `Blowfish`.
+  - For legacy compatibility requirements, isolate the implementation and add clear security warnings.
 - **Applies to**: All languages
 - **Tools**: SonarQube (S2070, S4790, S5547), Semgrep (crypto rules), Manual Review
 - **Principles**: CODE_QUALITY, SECURITY
-- **Version**: 1.0
+- **Version**: 2.0
 - **Status**: activated
 - **Severity**: medium
 
@@ -156,36 +197,58 @@
 - **Status**: activated
 - **Severity**: high
 
-### 📘 Rule S011 – GUIDs used for security purposes must be generated according to UUID v4 standard with CSPRNG
+### 📘 Rule S011 – Enable Encrypted Client Hello (ECH) for TLS
 
-- **Objective**: Prevent guessing, recreation, or exploitation of GUIDs when used as identifiers for sensitive resources, by ensuring GUIDs are generated according to UUID v4 standard with cryptographically secure random number generators (CSPRNG).
+- **Objective**: Prevent exposure of sensitive metadata during TLS handshake by enabling Encrypted Client Hello (ECH) to protect Server Name Indication (SNI) and other client hello fields.
 - **Details**:
-  - Avoid using UUID v1 as it may leak MAC address and timestamp.
-  - Do not use UUID v3/v5 as they are based on hash from input → can be recreated if input is known.
-  - UUID v4 must be randomly generated (random-based), using CSPRNG.
-  - Mandatory when GUID is used as: password reset ID, session ID, magic link, API key, authentication token...
+  - **Why ECH matters**:
+    - Standard TLS exposes SNI in plaintext during handshake
+    - Attackers can identify which sites users are visiting
+    - Network monitors can filter/block based on SNI
+  - **Required configuration**:
+    - Enable ECH in TLS settings (TLS 1.3 required)
+    - Configure ECH public keys properly
+    - Support HTTPS DNS records for ECH key distribution
+  - **Benefits**:
+    - Encrypts SNI and other sensitive handshake data
+    - Prevents traffic analysis based on destination
+    - Enhances user privacy
+  - Verify ECH is working using browser developer tools or TLS testing tools.
 - **Applies to**: All languages
-- **Tools**: Manual Review, Semgrep (uuid version rules), Static Analyzer, SonarQube (custom rule)
-- **Principles**: CODE_QUALITY, SECURITY
-- **Version**: 1.0
+- **Tools**: SSL Labs, testssl.sh, Browser DevTools, Manual TLS Config Review
+- **Principles**: SECURITY
+- **Version**: 2.0
 - **Status**: activated
-- **Severity**: high
+- **Severity**: medium
 
-### 📘 Rule S012 – Protect secrets and encrypt sensitive data
+### 📘 Rule S012 – Use secrets management solution for backend secrets
 
-- **Objective**: Protect encryption keys, passwords, access tokens, API keys... from exposure through source code, `.env` files, or logs. Ensure sensitive data is always encrypted and keys are managed securely through Key Vault or HSM.
+- **Objective**: Ensure all backend secrets are securely managed using a dedicated secrets management solution, never stored in source code or build artifacts.
 - **Details**:
-  - Do not store private keys, JWT secrets, passwords in `.env` files, config JSON, YAML without encryption or strict access management.
-  - Absolutely do not hardcode secrets in source code (even test keys).
-  - Must use secure secret management systems like AWS Secrets Manager, HashiCorp Vault, Azure Key Vault, GCP Secret Manager, or HSM.
-  - Sensitive data like payment information, passwords, PII must be encrypted before storing in database or storage.
-  - Logs must exclude or obfuscate secret information.
+  - **Must use a secrets management solution** (key vault) to:
+    - Create secrets securely
+    - Store secrets with encryption at rest
+    - Control access with fine-grained permissions
+    - Rotate and destroy secrets safely
+  - **Types of secrets to manage**:
+    - Passwords and credentials
+    - Cryptographic key material
+    - Database connection strings
+    - Third-party system integrations
+    - TOTP seeds and internal secrets
+    - API keys
+  - **Prohibited practices**:
+    - Secrets in application source code
+    - Secrets in build artifacts or container images
+    - Secrets in environment files committed to repos
+  - **For L3 (high-security) applications**: Must use hardware-backed solution (HSM).
+  - Recommended tools: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager.
 - **Applies to**: All languages
-- **Tools**: SonarQube (S2068, S5547), GitLeaks, TruffleHog, Semgrep (hardcoded-secrets), Secret Scanner CI/CD
-- **Principles**: SECURITY
-- **Version**: 1.0
+- **Tools**: Vault, AWS Secrets Manager, Azure Key Vault, GitLeaks, TruffleHog, HSM
+- **Principles**: CODE_QUALITY, SECURITY
+- **Version**: 2.0
 - **Status**: activated
-- **Severity**: medium
+- **Severity**: critical
 
 ### 📘 Rule S013 – Always use TLS for all connections
 
@@ -272,32 +335,33 @@
 - **Status**: activated
 - **Severity**: critical
 
-### 📘 Rule S018 – Prefer Allow List for Input Validation
+### 📘 Rule S018 – Do not store sensitive data in browser storage
 
-- **Objective**: Ensure all user inputs or external data sources are strictly validated by accepting only known good values. This reduces the risk of attacks like XSS, SQL Injection, and other security issues caused by malformed or unexpected input.
+- **Objective**: Prevent sensitive data exposure by ensuring browser storage mechanisms do not contain sensitive information, except for session tokens.
 - **Details**:
-  - Always use an **Allow List** to validate input values – only allow explicitly defined values or types (e.g., positive integers, valid emails, safe strings).
-  - Avoid using **Deny Lists** because:
-    - They are prone to bypass due to incomplete coverage.
-    - They fail to catch new or unknown attack patterns.
-  - Apply to all input sources, including:
-    - HTML form fields
-    - URL parameters, HTTP headers, cookies
-    - REST API payloads or batch file inputs
-    - RSS feeds, webhook payloads, etc.
-  - Validation should be based on:
-    - Data types (number, string, boolean)
-    - Specific patterns (regex, enums)
-    - Range or length restrictions
-  - Use standard validation libraries where available:
-    - `class-validator`, `joi`, `yup`, `express-validator` (JavaScript)
-    - `javax.validation` (Java), `FluentValidation` (C#), `Cerberus` (Python), etc.
+  - **Browser storage types covered**:
+    - `localStorage` (persistent, accessible by JavaScript)
+    - `sessionStorage` (tab-scoped, accessible by JavaScript)
+    - `IndexedDB` (client-side database)
+    - Cookies (when not HttpOnly)
+  - **Prohibited data in browser storage**:
+    - Passwords or credentials
+    - Personal Identifiable Information (PII)
+    - Financial data (credit cards, bank accounts)
+    - API keys or secrets
+    - Encryption keys
+  - **Exception**: Session tokens may be stored, but:
+    - Use `HttpOnly` cookies when possible
+    - Apply short expiration times
+    - Implement proper token rotation
+  - XSS attacks can access all JavaScript-readable storage.
+  - Use server-side sessions for sensitive data instead.
 - **Applies to**: All languages
-- **Tools**: Static Analysis (Semgrep, SonarQube), Manual Review, Input Validation Libraries
-- **Principles**: SECURITY
-- **Version**: 1.1
-- **Status**: draft
-- **Severity**: medium
+- **Tools**: Browser DevTools, Static Analysis (Semgrep, ESLint), Manual Code Review, Security Audit
+- **Principles**: CODE_QUALITY, SECURITY
+- **Version**: 2.0
+- **Status**: activated
+- **Severity**: high
 
 ### 📘 Rule S019 – Sanitize input before sending emails to prevent SMTP Injection
 
@@ -333,21 +397,28 @@
 - **Status**: activated
 - **Severity**: high
 
-### 📘 Rule S021 – Sanitize user-generated Markdown, CSS, and XSL content
+### 📘 Rule S021 – Set Referrer-Policy to prevent sensitive data leakage
 
-- **Objective**: Prevent script injection via user-generated content in Markdown, CSS, or XSL.
+- **Objective**: Prevent leakage of sensitive URL data (path, query parameters, hostname) to third-party services via the `Referer` HTTP header.
 - **Details**:
-  - Attackers may abuse Markdown parser or render engine to inject JS, malicious links, or dangerous attributes (`onload`, `style=...`).
-  - For XSL, non-sandboxed processing or external entity access can lead to XXE or XSLT injection.
-  - Prevention:
-    - Use libraries like `marked.js`, `markdown-it` with `sanitize: true` or XSS filter plugins.
-    - Avoid rendering tags like `style`, `script`, `iframe`, or `javascript:` URLs.
-    - For CSS/XSL, use sandboxed rendering engines and escape output before rendering.
+  - **Why it matters**:
+    - `Referer` header can expose sensitive data in URLs to external sites
+    - Internal application hostnames may reveal infrastructure details
+    - Query parameters may contain tokens, IDs, or PII
+  - **Implementation methods**:
+    - HTTP response header: `Referrer-Policy: strict-origin-when-cross-origin`
+    - HTML meta tag: `<meta name="referrer" content="strict-origin-when-cross-origin">`
+    - HTML element attributes: `rel="noreferrer"` on links
+  - **Recommended policies**:
+    - `strict-origin-when-cross-origin` (default, balanced)
+    - `same-origin` (stricter, only same-origin gets referrer)
+    - `no-referrer` (strictest, never send referrer)
+  - For internal non-public applications, use stricter policies to protect hostnames.
 - **Applies to**: All languages
-- **Tools**: DOMPurify, sanitize-html, markdown-it, Bandit (Python), Manual Review, SonarQube (custom rule)
+- **Tools**: Browser DevTools, Security Headers Scanner, OWASP ZAP, Manual Review
 - **Principles**: CODE_QUALITY, SECURITY
-- **Version**: 1.1
-- **Status**: draft
+- **Version**: 2.0
+- **Status**: activated
 - **Severity**: medium
 
 ### 📘 Rule S022 – Escape data properly based on output context
@@ -369,21 +440,27 @@
 - **Status**: activated
 - **Severity**: medium
 
-### 📘 Rule S023 – Prevent JSON Injection and JSON eval attacks
+### 📘 Rule S023 – Use output encoding when building dynamic JavaScript/JSON
 
-- **Objective**: Prevent JavaScript execution via unsafe JSON handling or injection attacks.
+- **Objective**: Prevent JavaScript and JSON injection by applying proper output encoding when dynamically building JavaScript content or JSON data.
 - **Details**:
-  - Never use `eval()` to process JSON from users.
-  - Use proper JSON parsers:
-    - JavaScript: `JSON.parse()`
-    - Python: `json.loads()`
-    - Java: `Gson`, `Jackson`, `ObjectMapper`
-  - When rendering raw JSON into HTML, escape dangerous sequences like `</script>` or `</`.
-  - Validate data before embedding JSON into `<script>` tags.
+  - **When building dynamic JavaScript**:
+    - Encode data before inserting into JS strings
+    - Escape characters: `\`, `'`, `"`, `<`, `>`, `&`, newlines
+    - Never use `eval()` or `new Function()` with user data
+  - **When building JSON responses**:
+    - Use native JSON serializers (`JSON.stringify()`, `json.dumps()`)
+    - Escape `</script>` sequences when embedding in HTML
+    - Validate JSON structure before parsing
+  - **Dangerous patterns to avoid**:
+    - String concatenation to build JS: `"var x = '" + userInput + "'"`
+    - Inline event handlers with user data
+    - Template literals with unescaped user input
+  - Use Content Security Policy (CSP) as defense-in-depth.
 - **Applies to**: All languages
-- **Tools**: ESLint (`no-eval`), Semgrep (`eval-dynamic`, `json-injection`), Bandit, SonarQube (S1523), Manual Review
+- **Tools**: ESLint (`no-eval`), Semgrep (json-injection), SonarQube (S1523, S5334), Manual Review
 - **Principles**: CODE_QUALITY, SECURITY
-- **Version**: 1.0
+- **Version**: 2.0
 - **Status**: activated
 - **Severity**: high
 
@@ -425,47 +502,59 @@
 - **Status**: activated
 - **Severity**: medium
 
-### 📘 Rule S026 – Apply JSON Schema Validation to input data
+### 📘 Rule S026 – Use TLS encryption for all inbound and outbound connections
 
-- **Objective**: Ensure all incoming JSON is fully validated by schema (structure, types, constraints) before processing.
+- **Objective**: Ensure all application connections use encrypted TLS protocol, with no fallback to insecure or unencrypted protocols.
 - **Details**:
-  - JSON schema can enforce:
-    - Required fields, type enforcement
-    - Constraints like length, min/max values, format checks
-    - Reduce injection risk or logic bugs from malformed JSON
-  - Language-specific tools:
-    - Java: use Jackson + Hibernate Validator (`@Valid`, `@Email`, `@Min`)
-    - JavaScript: use `ajv`, `joi`
-    - Python: use `jsonschema`, `pydantic`
-    - Go: use `gojsonschema`
-    - C#: use `NJsonSchema`
+  - **All connections must use TLS**:
+    - Inbound: API endpoints, web interfaces, webhooks
+    - Outbound: external APIs, databases, partner systems
+  - **Connection types covered**:
+    - Monitoring systems and health checks
+    - Management tools and admin interfaces
+    - Remote access and SSH connections
+    - Middleware and message queues
+    - Database connections (PostgreSQL, MySQL, MongoDB)
+    - Mainframe and legacy system integrations
+    - Partner and external API calls
+  - **Requirements**:
+    - TLS 1.2 minimum, prefer TLS 1.3
+    - No fallback to HTTP, unencrypted protocols
+    - Certificate validation enabled
+    - Strong cipher suites only
+  - Disable debug modes that bypass TLS in production.
 - **Applies to**: All languages
-- **Tools**: AJV, jsonschema, Joi, Pydantic, Hibernate Validator, SonarQube (custom rule), Manual Review
+- **Tools**: SSL Labs, testssl.sh, nmap, Network Traffic Analysis, Manual Config Review
 - **Principles**: CODE_QUALITY, SECURITY
-- **Version**: 1.0
+- **Version**: 2.0
 - **Status**: activated
-- **Severity**: medium
+- **Severity**: critical
 
-### 📘 Rule S027 – Never expose secrets in source code or Git
+### 📘 Rule S027 – Validate mTLS client certificates before authentication
 
-- **Objective**: Prevent leakage of credentials, API keys, tokens, or sensitive config via source code or version control.
+- **Objective**: Ensure mTLS client certificates are properly validated and trusted before using certificate identity for authentication or authorization decisions.
 - **Details**:
-  - Common leak sources:
-    - `.env`, `config.yaml`, `secrets.json`, or hardcoded values like `API_KEY`, `JWT_SECRET`
-  - Mitigation:
-    - Use `.gitignore` to exclude secret files
-    - Scan commits with GitLeaks, TruffleHog, detect-secrets
-    - Add pre-commit hooks to block secret-containing files
-    - If leaked, rotate keys, revoke tokens, and clean Git history
-  - Additional notes:
-    - Avoid plaintext secrets in CI/CD pipelines
-    - Store secrets in a secure vault (e.g., AWS Secrets Manager, HashiCorp Vault)
+  - **Before trusting certificate identity**:
+    - Verify certificate is signed by trusted CA
+    - Check certificate has not expired
+    - Validate certificate is not revoked (CRL/OCSP)
+    - Confirm certificate subject/SAN matches expected identity
+  - **Certificate validation requirements**:
+    - Full chain validation up to root CA
+    - Check Extended Key Usage for client authentication
+    - Verify certificate purpose and constraints
+  - **Common mistakes to avoid**:
+    - Accepting any valid certificate without identity check
+    - Skipping revocation checks
+    - Trusting self-signed certificates without explicit pinning
+    - Using certificate CN without proper validation
+  - Log all certificate validation failures for security monitoring.
 - **Applies to**: All languages
-- **Tools**: GitLeaks, TruffleHog, detect-secrets, git-secrets, SonarQube (custom rule)
+- **Tools**: OpenSSL, mTLS Testing Tools, Certificate Validator, Manual Config Review
 - **Principles**: CODE_QUALITY, SECURITY
-- **Version**: 1.0
+- **Version**: 2.0
 - **Status**: activated
-- **Severity**: medium
+- **Severity**: critical
 
 ### 📘 Rule S028 – Limit upload file size and number of files per user
 
@@ -620,43 +709,60 @@
 - **Status**: activated
 - **Severity**: medium
 
-### 📘 Rule S035 – Set the `Path` attribute for Session Cookies to limit access scope
+### 📘 Rule S035 – Host separate applications on different hostnames
 
-- **Objective**: Reduce the risk of session cookie leaks or abuse across multiple apps under the same domain (e.g., `/app1` and `/app2`) by limiting cookie scope via the `Path` attribute.
+- **Objective**: Leverage same-origin policy restrictions by hosting separate applications on different hostnames to isolate resources, cookies, and prevent cross-application attacks.
 - **Details**:
-  - Cookies with `Path=/` are sent with **all requests under the same domain**, including unrelated applications.
-  - Risk in shared domain environments:
-    - Example: `example.com/app1`, `example.com/app2`
-    - Cookie from `app1` will also be sent to `app2` unless `Path` is restricted.
-  - Best practices:
-    - Set specific `Path` (e.g., `/app1/`) so cookies only work within that path.
-    - Avoid empty `Path` (`""`) – which defaults to `/`.
+  - **Same-origin policy benefits**:
+    - Prevents scripts from one origin accessing resources from another
+    - Isolates cookies and storage per hostname
+    - Limits impact of XSS to single application
+  - **Hosting requirements**:
+    - Each application should have its own hostname/subdomain
+    - Example: `app1.example.com`, `app2.example.com` (good)
+    - Avoid: `example.com/app1`, `example.com/app2` (shared origin)
+  - **Restrictions enforced**:
+    - Document/script isolation between origins
+    - Cookie isolation (with proper domain settings)
+    - localStorage/sessionStorage separation
+    - CORS enforcement for cross-origin requests
+  - Use subdomains or separate domains for:
+    - Admin panels vs public sites
+    - API servers vs frontend apps
+    - Multi-tenant applications
 - **Applies to**: All languages
-- **Tools**: Static Analysis, Manual Review, Chrome DevTools, Postman, SonarQube (custom rule)
+- **Tools**: Manual Architecture Review, DNS Configuration Audit, Browser DevTools
 - **Principles**: CODE_QUALITY, SECURITY
-- **Version**: 1.0
+- **Version**: 2.0
 - **Status**: activated
 - **Severity**: medium
 
-### 📘 Rule S036 – Prevent LFI and RFI using path validation and allow-lists
+### 📘 Rule S036 – Use internal data for file paths, validate user filenames strictly
 
-- **Objective**: Block Local File Inclusion (LFI) and Remote File Inclusion (RFI) attacks where attackers access sensitive files (e.g., `/etc/passwd`, `C:\Windows\system32`) or execute code from external URLs.
+- **Objective**: Prevent path traversal, LFI, RFI, and SSRF attacks by using internally generated file paths instead of user-submitted filenames, with strict validation when user input is unavoidable.
 - **Details**:
-  - **LFI**: The app accepts unchecked file paths → attacker reads internal files.
-  - **RFI**: The app includes external files from user input → leads to Remote Code Execution.
-  - Preventive measures:
-    - Use **Allow List** of valid filenames/paths.
-    - Never include/load user input directly.
-    - Disallow URL usage in include/require/load/open.
-    - Disable remote includes (e.g., `allow_url_include=Off` in PHP).
-    - Normalize paths to remove `../` (path traversal).
-    - Restrict permissions via sandboxing.
+  - **Preferred approach** - Use internal data:
+    - Generate file paths from internal IDs or UUIDs
+    - Map user selections to predefined safe paths
+    - Store file metadata in database, not in filenames
+  - **When user filenames are required**:
+    - Strip path separators (`/`, `\`, `..`)
+    - Validate against allow-list of characters
+    - Limit filename length
+    - Sanitize file extensions
+    - Normalize paths before validation
+  - **Attacks prevented**:
+    - Path traversal (`../../etc/passwd`)
+    - Local File Inclusion (LFI)
+    - Remote File Inclusion (RFI)
+    - Server-Side Request Forgery (SSRF)
+  - Never use user input directly in: `include()`, `require()`, `open()`, `readFile()`, file download paths.
 - **Applies to**: All languages
-- **Tools**: Static Analysis, OWASP ZAP, Burp Suite, Manual Review, SonarQube (custom rule)
+- **Tools**: Static Analysis, OWASP ZAP, Burp Suite, Semgrep (path-traversal), Manual Review
 - **Principles**: CODE_QUALITY, SECURITY
-- **Version**: 1.0
+- **Version**: 2.0
 - **Status**: activated
-- **Severity**: high
+- **Severity**: critical
 
 ### 📘 Rule S037 – Set anti-cache headers to prevent sensitive data leakage
 
@@ -700,23 +806,30 @@
 - **Status**: activated
 - **Severity**: medium
 
-### 📘 Rule S039 – Never transmit Session Tokens via URL parameters
+### 📘 Rule S039 – TLS clients must validate server certificates
 
-- **Objective**: Prevent session hijacking by ensuring session tokens are not stored in browser history, server logs, proxy logs, or leaked via Referrer headers.
+- **Objective**: Ensure TLS clients validate certificates received from servers before establishing secure communication to prevent MITM attacks.
 - **Details**:
-  - Risks of token in URL (e.g., `https://example.com/dashboard?sessionId=abc123`):
-    - Saved in browser history
-    - Logged on server/load balancer
-    - Leaked via `Referer` to third parties
-  - Best practices:
-    - Use `Secure`, `HttpOnly` cookies for token storage
-    - Use headers or body for API auth – never query string
+  - **Required certificate validation**:
+    - Verify certificate is signed by trusted CA
+    - Check certificate chain up to root CA
+    - Validate certificate has not expired
+    - Confirm hostname matches certificate CN/SAN
+  - **Do NOT disable validation**:
+    - Never set `rejectUnauthorized: false` (Node.js)
+    - Never set `verify=False` (Python requests)
+    - Never set `InsecureSkipVerify: true` (Go)
+    - Never ignore SSL errors in production
+  - **Certificate revocation**:
+    - Check CRL or OCSP when possible
+    - Consider OCSP stapling for performance
+  - For development/testing only: use self-signed certs with explicit trust, not disabled validation.
 - **Applies to**: All languages
-- **Tools**: Static Analysis, Manual Review, Burp Suite, Postman, SonarQube (custom rule)
-- **Principles**: SECURITY
-- **Version**: 1.0
+- **Tools**: SSL Labs, testssl.sh, Static Analysis, Manual Code Review
+- **Principles**: CODE_QUALITY, SECURITY
+- **Version**: 2.0
 - **Status**: activated
-- **Severity**: high
+- **Severity**: critical
 
 ### 📘 Rule S040 – Regenerate Session Token after login to prevent Session Fixation
 
@@ -734,7 +847,7 @@
 - **Tools**: Static Analysis, Manual Review, OWASP ZAP, Burp Suite, SonarQube (custom rule)
 - **Principles**: SECURITY
 - **Version**: 1.1
-- **Status**: draft
+- **Status**: activated
 - **Severity**: high
 
 ### 📘 Rule S041 – Session Tokens must be invalidated after logout or expiration
@@ -787,7 +900,7 @@
 - **Tools**: Manual Review, Static Analysis (Token Revocation Logic), SonarQube (custom rule)
 - **Principles**: CODE_QUALITY, SECURITY
 - **Version**: 1.1
-- **Status**: draft
+- **Status**: activated
 - **Severity**: medium
 
 ### 📘 Rule S044 – Require re-authentication before modifying critical information
@@ -823,61 +936,86 @@
 - **Status**: activated
 - **Severity**: medium
 
-### 📘 Rule S046 – Notify users of critical account changes
+### 📘 Rule S046 – Use algorithm allowlist for self-contained tokens
 
-- **Objective**: Alert users to sensitive actions to detect potential compromise and allow timely intervention.
+- **Objective**: Prevent algorithm confusion and downgrade attacks by restricting token signing/verification to an explicit allowlist of algorithms.
 - **Details**:
-  - Notify users when performing actions such as:
-    - Password reset
-    - Changing email or phone number
-    - Login from new devices or suspicious IPs
-  - Notification channels: Email, Push Notification, or SMS
-  - **Do not include sensitive info** (e.g., password, token, unencrypted links)
-  - Log these events for security audit purposes
+  - **Must use algorithm allowlist**:
+    - Define permitted algorithms explicitly for each context
+    - Validate algorithm before processing token
+    - Reject tokens using algorithms not in allowlist
+  - **Critical requirement**:
+    - **Never** allow the `none` algorithm
+    - Prefer either symmetric OR asymmetric algorithms, not both
+  - **If both symmetric and asymmetric needed**:
+    - Implement key type validation
+    - Prevent key confusion attacks (using symmetric key as asymmetric)
+    - Use separate key stores for different algorithm types
+  - **Recommended algorithms**:
+    - Symmetric: HS256, HS384, HS512
+    - Asymmetric: RS256, RS384, RS512, ES256, ES384, ES512
+  - Validate algorithm in token header matches expected algorithm before verification.
 - **Applies to**: All languages
-- **Tools**: Manual Review, Security Test, Notification Audit, SonarQube (custom rule)
+- **Tools**: JWT Debugger, Static Analysis, Manual Code Review, Security Test
 - **Principles**: CODE_QUALITY, SECURITY
-- **Version**: 1.1
-- **Status**: draft
-- **Severity**: medium
+- **Version**: 2.0
+- **Status**: activated
+- **Severity**: critical
 
-### 📘 Rule S047 – Secure temporary passwords and activation codes
+### 📘 Rule S047 – Protect OAuth code flow against CSRF attacks
 
-- **Objective**: Ensure that temporary passwords and activation codes are secure, unpredictable, single-use, and time-limited.
+- **Objective**: Prevent browser-based CSRF attacks that could trigger unauthorized OAuth token requests by implementing PKCE or state parameter validation.
 - **Details**:
-  - Temporary credentials must:
-    - Be randomly generated using CSPRNG
-    - Be at least **6 characters long**, and contain **letters and numbers**
-    - Have short validity: **15 minutes to 24 hours**
-    - Be **one-time use only**
-    - **Must not** be used as permanent passwords
-  - Additional protection:
-    - Store only hashed values if persisted
-    - Invalidate after use
-    - Disallow regeneration until expired
+  - **OAuth code flow CSRF protection methods**:
+    - **PKCE (Proof Key for Code Exchange)** - Recommended:
+      - Generate cryptographically random `code_verifier`
+      - Send `code_challenge` (hash of verifier) in authorization request
+      - Send `code_verifier` in token request
+      - Server validates challenge matches verifier
+    - **State parameter**:
+      - Generate unique, unpredictable `state` value
+      - Send `state` in authorization request
+      - Validate `state` in callback matches sent value
+      - Bind state to user session
+  - **Requirements**:
+    - Use PKCE for all public clients (SPAs, mobile apps)
+    - Use state parameter as minimum for confidential clients
+    - Never reuse state or PKCE values
+  - Reject authorization responses without valid state/PKCE.
 - **Applies to**: All languages
-- **Tools**: Manual Review, Static Analysis, Audit Flow, SonarQube (custom rule)
+- **Tools**: OAuth Security Testing, Manual Code Review, OWASP ZAP
 - **Principles**: CODE_QUALITY, SECURITY
-- **Version**: 1.0
+- **Version**: 2.0
 - **Status**: activated
 - **Severity**: high
 
-### 📘 Rule S048 – Do not expose current password during reset flow
+### 📘 Rule S048 – Validate OAuth redirect URIs with exact string comparison
 
-- **Objective**: Ensure the current user password is never revealed or sent in any step of the password reset process.
+- **Objective**: Prevent OAuth redirect attacks by validating redirect URIs against a client-specific allowlist using exact string comparison, not pattern matching.
 - **Details**:
-  - **Never display or send the current password** to the user
-  - Do not email or SMS old passwords
-  - During password reset:
-    - Only ask for new password (with confirmation)
-    - Use OTP/email/token for verification, not current password
-  - If changing password while logged in, require **manual entry of current password**, never show it
+  - **Redirect URI validation requirements**:
+    - Use exact string comparison (no wildcards, no patterns)
+    - Validate against pre-registered URIs only
+    - Each OAuth client must have its own allowlist
+  - **Do NOT allow**:
+    - Wildcard redirects (`*.example.com`)
+    - Partial matching (`example.com/callback*`)
+    - Open redirects to any URL
+    - Localhost in production (except for development clients)
+  - **Pre-registration process**:
+    - Register all valid redirect URIs during client creation
+    - Require admin approval for URI changes
+    - Audit redirect URI changes
+  - **Common attack patterns blocked**:
+    - Subdomain takeover (`attacker.example.com`)
+    - Path traversal in redirect
+    - Parameter injection in URI
 - **Applies to**: All languages
-- **Tools**: Manual Review, Penetration Test, SonarQube (custom rule)
-- **Principles**: SECURITY
-- **Version**: 1.0
+- **Tools**: OAuth Security Testing, Manual Config Review, Penetration Testing
+- **Principles**: CODE_QUALITY, SECURITY
+- **Version**: 2.0
 - **Status**: activated
-- **Severity**: medium
+- **Severity**: critical
 
 ### 📘 Rule S049 – Authentication codes must expire quickly
 
@@ -896,26 +1034,32 @@
 - **Status**: activated
 - **Severity**: medium
 
-### 📘 Rule S050 – Session tokens must have minimum 64-bit entropy and use secure algorithms
+### 📘 Rule S050 – Reference tokens must be unique with 128-bit entropy using CSPRNG
 
-- **Objective**: Prevent attackers from predicting or forging session tokens by ensuring sufficient length, entropy, and cryptographic safety.
+- **Objective**: Ensure reference tokens (session tokens, opaque tokens) are unpredictable and resistant to brute-force attacks by using cryptographically secure generation.
 - **Details**:
-  - Session tokens must have at least **64-bit entropy**, recommended: **128-bit or 256-bit**
-  - Use approved cryptographic algorithms:
-    - HMAC-SHA-256
-    - AES-256
-    - ChaCha20
-  - Avoid weak algorithms:
-    - MD5
-    - SHA-1
-  - Do not generate tokens using `Math.random()` or short guessable strings
-  - Always use CSPRNG for token generation
+  - **Token requirements**:
+    - Generated using CSPRNG (Cryptographically Secure Pseudo-Random Number Generator)
+    - Minimum **128 bits of entropy** (recommended: 256 bits)
+    - Must be unique across all active sessions
+  - **Secure generation methods**:
+    - Node.js: `crypto.randomBytes(32)`
+    - Python: `secrets.token_hex(32)`
+    - Java: `SecureRandom`
+    - Go: `crypto/rand`
+  - **Do NOT use**:
+    - `Math.random()` or similar non-cryptographic RNG
+    - Sequential or predictable patterns
+    - User-derivable values (username, timestamp alone)
+    - Short tokens (< 128 bits)
+  - Store tokens securely (hashed if possible) and transmit only over TLS.
+  - Implement token rotation and expiration policies.
 - **Applies to**: All languages
-- **Tools**: Manual Review, Static Analysis, SonarQube (custom rule)
+- **Tools**: Static Analysis, Security Audit, CSPRNG Verification, Manual Code Review
 - **Principles**: CODE_QUALITY, SECURITY
-- **Version**: 1.0
+- **Version**: 2.0
 - **Status**: activated
-- **Severity**: medium
+- **Severity**: high
 
 ### 📘 Rule S051 – Support 12–64 character passwords; reject >128 characters
 
@@ -949,25 +1093,31 @@
 - **Status**: activated
 - **Severity**: medium
 
-### 📘 Rule S053 – Only use secure OTP algorithms like HOTP/TOTP
+### 📘 Rule S053 – Return generic error messages, hide internal details
 
-- **Objective**: Ensure OTPs are secure against spoofing and replay attacks by using safe, standard algorithms.
+- **Objective**: Prevent exposure of sensitive internal system data by returning generic error messages to consumers when unexpected or security-sensitive errors occur.
 - **Details**:
-  - **Do not use**:
-    - Weak algorithms like `MD5`, `SHA-1` (deprecated)
-    - OTPs without expiration or usage limits
-  - **Use standards**:
-    - `HOTP` (HMAC-based OTP – [RFC 4226](https://datatracker.ietf.org/doc/html/rfc4226))
-    - `TOTP` (Time-based OTP – [RFC 6238](https://datatracker.ietf.org/doc/html/rfc6238))
-  - Recommended libraries:
-    - `PyOTP` (Python), `otplib` (Node.js), `Google Authenticator` SDK (Java)
-  - Always enforce time-based expiration (typically 30–300 seconds)
+  - **Never expose to consumers**:
+    - Stack traces or exception details
+    - Database queries or SQL errors
+    - Secret keys, tokens, or credentials
+    - Internal file paths or system configuration
+    - Server version or technology stack details
+  - **Return generic messages**:
+    - "An unexpected error occurred. Please try again later."
+    - "Request could not be processed."
+    - Use error codes for support reference (e.g., `ERR-12345`)
+  - **Internal handling**:
+    - Log full error details server-side for debugging
+    - Include correlation IDs in logs for traceability
+    - Use structured logging with proper log levels
+  - Differentiate between client errors (4xx) and server errors (5xx) without leaking details.
 - **Applies to**: All languages
-- **Tools**: Manual Review, Unit Test, Static Analysis, SonarQube (custom rule)
+- **Tools**: Static Analysis, Penetration Testing, Error Response Audit, Manual Code Review
 - **Principles**: CODE_QUALITY, SECURITY
-- **Version**: 1.0
+- **Version**: 2.0
 - **Status**: activated
-- **Severity**: medium
+- **Severity**: high
 
 ### 📘 Rule S054 – Avoid using default accounts like "admin", "root", "sa"
 
@@ -1050,19 +1200,57 @@
 - **Status**: activated
 - **Severity**: medium
 
-### 📘 Rule S059 – Configure Allow List for server-side outbound requests
+### 📘 Rule S059 – Disable debug modes in production environments
 
-- **Objective**: Reduce risks from the server making outbound requests to untrusted systems (SSRF, malicious downloads, data leaks).
+- **Objective**: Prevent exposure of debugging features and information leakage by ensuring all debug modes are disabled in production environments.
 - **Details**:
-  - All outbound connections (HTTP, FTP, DNS, etc.) must be restricted via allow lists.
-  - Do not let the server freely access the internet or unknown domains by default.
-  - Example restrictions:
-    - Only allow sending files to trusted storage or domains like `https://trusted.example.com`.
-    - Containers may only use DNS for allowed addresses.
-  - In cloud/serverless environments, restrict outbound traffic using IAM policies, security groups, or network ACLs.
+  - **Debug features to disable in production**:
+    - Framework debug modes (Django `DEBUG=False`, Flask `debug=False`)
+    - Detailed error pages with stack traces
+    - Debug endpoints (`/debug`, `/trace`, `/actuator`)
+    - SQL query logging to responses
+    - Verbose logging that exposes sensitive data
+  - **Common debug indicators to check**:
+    - `DEBUG=true` in environment variables
+    - Development server warnings in logs
+    - Source maps exposed in frontend
+    - Test/mock endpoints accessible
+  - **Verification steps**:
+    - Audit configuration files for debug settings
+    - Test error responses for information leakage
+    - Check HTTP headers for debug information
+    - Review CI/CD pipelines for proper environment separation
+  - Use environment-specific configurations, never deploy development configs to production.
 - **Applies to**: All languages
-- **Tools**: Manual Config Review, Firewall/Proxy Logs, CloudTrail, Burp Suite Test, SonarQube (custom rule)
-- **Principles**: SECURITY
-- **Version**: 1.1
-- **Status**: draft
-- **Severity**: low
+- **Tools**: Configuration Audit, Penetration Testing, OWASP ZAP, Environment Checker
+- **Principles**: CODE_QUALITY, SECURITY
+- **Version**: 2.0
+- **Status**: activated
+- **Severity**: high
+
+### 📘 Rule S060 – Enforce minimum password length of 8 characters, recommend 15+
+
+- **Objective**: Ensure user-set passwords meet minimum length requirements to provide adequate security against brute-force and dictionary attacks.
+- **Details**:
+  - **Minimum requirements**:
+    - Passwords must be at least **8 characters** in length
+    - A minimum of **15 characters is strongly recommended** for better security
+  - **Implementation guidelines**:
+    - Enforce 8-character minimum at registration and password change
+    - Display strength indicator encouraging longer passwords
+    - Show recommendation for 15+ characters without blocking shorter valid passwords
+  - **Rationale**:
+    - 8 characters: baseline protection against common attacks
+    - 15+ characters: significantly increases resistance to brute-force
+    - Longer passwords (passphrases) are easier to remember and more secure
+  - **User experience considerations**:
+    - Provide real-time feedback on password strength
+    - Suggest passphrase approach (e.g., "correct horse battery staple")
+    - Do not impose complex character requirements that reduce usability
+  - Combine with other password policies (breach detection, no common passwords).
+- **Applies to**: All languages
+- **Tools**: Static Analysis, Unit Test, Password Strength Libraries (zxcvbn), Manual Review
+- **Principles**: CODE_QUALITY, SECURITY
+- **Version**: 2.0
+- **Status**: activated
+- **Severity**: medium