@sun-asterisk/sunlint 1.3.26 → 1.3.28

package/origin-rules/security-en.md

@@ -13,8 +13,8 @@
 - **Applies to**: All languages
 - **Tools**: SonarQube (S4524), PMD (SecurityCodeGuidelines), Manual Review, Unit Test
 - **Principles**: CODE_QUALITY, SECURITY
-- **Version**: 1.0
-- **Status**: activated
+- **Version**: 1.1
+- **Status**: draft
 - **Severity**: critical
 
 ### 📘 Rule S002 – Avoid IDOR vulnerabilities in CRUD operations
@@ -28,8 +28,8 @@
 - **Applies to**: All languages
 - **Tools**: SonarQube (S6142, S2076), Semgrep (custom rule), Manual Review
 - **Principles**: CODE_QUALITY, SECURITY
-- **Version**: 1.0
-- **Status**: activated
+- **Version**: 1.1
+- **Status**: draft
 - **Severity**: critical
 
 ### 📘 Rule S003 – URL redirects must be within an allow list
@@ -121,8 +121,8 @@
 - **Applies to**: All languages
 - **Tools**: Manual Review, Semgrep (custom rule), Secret Scanners, SonarQube (custom rule)
 - **Principles**: CODE_QUALITY, MAINTAINABILITY, SECURITY
-- **Version**: 1.0
-- **Status**: activated
+- **Version**: 1.1
+- **Status**: draft
 - **Severity**: low
 
 ### 📘 Rule S009 – Do not use insecure encryption modes, padding, or cryptographic algorithms
@@ -276,38 +276,39 @@
 
 - **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.
 - **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.
+  - 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.
 - **Applies to**: All languages
 - **Tools**: Static Analysis (Semgrep, SonarQube), Manual Review, Input Validation Libraries
 - **Principles**: SECURITY
-- **Version**: 1.0
-- **Status**: activated
+- **Version**: 1.1
+- **Status**: draft
 - **Severity**: medium
 
 ### 📘 Rule S019 – Sanitize input before sending emails to prevent SMTP Injection
+
 - **Objective**: Prevent SMTP/IMAP injection by removing control characters and ensuring proper formatting of user input used in email sending.
 - **Details**:
-    - SMTP Injection occurs when input contains `\r`, `\n` which can inject new lines or alter email content.
-    - Risks: hidden email sending, modified content, header spoofing, or spam.
-    - Prevention:
-        - Strip or reject control characters (`\n`, `\r`) in `to`, `subject`, `cc`, `bcc`, `reply-to`.
-        - Validate email format strictly before use.
-        - Prefer using secure email APIs like SendGrid, Amazon SES, Mailgun instead of direct SMTP protocol.
+  - SMTP Injection occurs when input contains `\r`, `\n` which can inject new lines or alter email content.
+  - Risks: hidden email sending, modified content, header spoofing, or spam.
+  - Prevention:
+    - Strip or reject control characters (`\n`, `\r`) in `to`, `subject`, `cc`, `bcc`, `reply-to`.
+    - Validate email format strictly before use.
+    - Prefer using secure email APIs like SendGrid, Amazon SES, Mailgun instead of direct SMTP protocol.
 - **Applies to**: All languages
 - **Tools**: Semgrep (regex match), Manual Review, Static Analysis, SonarQube (custom rule)
 - **Principles**: SECURITY
@@ -316,14 +317,15 @@
 - **Severity**: medium
 
 ### 📘 Rule S020 – Avoid using `eval()` or executing dynamic code
+
 - **Objective**: Prevent Remote Code Execution (RCE) by disallowing use of dynamic code execution functions like `eval()`, `Function()`, `exec()`, `Runtime.exec()` with user-controlled input.
 - **Details**:
-    - Functions like `eval()`, `exec()`, `new Function()`, or `setTimeout(..., string)` allow arbitrary code execution, dangerous with untrusted input.
-    - Attackers can execute system commands, read files, or manipulate databases remotely.
-    - Alternatives to `eval`:
-        - Object mapping or switch-case for dynamic logic
-        - JSON parsing for data structures
-        - `safe-eval` library (only within a sandboxed scope)
+  - Functions like `eval()`, `exec()`, `new Function()`, or `setTimeout(..., string)` allow arbitrary code execution, dangerous with untrusted input.
+  - Attackers can execute system commands, read files, or manipulate databases remotely.
+  - Alternatives to `eval`:
+    - Object mapping or switch-case for dynamic logic
+    - JSON parsing for data structures
+    - `safe-eval` library (only within a sandboxed scope)
 - **Applies to**: All languages
 - **Tools**: Semgrep (eval-detection rules), ESLint (`no-eval`), SonarQube (S1523), Static Analyzer
 - **Principles**: SECURITY
@@ -332,32 +334,34 @@
 - **Severity**: high
 
 ### 📘 Rule S021 – Sanitize user-generated Markdown, CSS, and XSL content
+
 - **Objective**: Prevent script injection via user-generated content in Markdown, CSS, or XSL.
 - **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.
+  - 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.
 - **Applies to**: All languages
 - **Tools**: DOMPurify, sanitize-html, markdown-it, Bandit (Python), Manual Review, SonarQube (custom rule)
 - **Principles**: CODE_QUALITY, SECURITY
-- **Version**: 1.0
-- **Status**: activated
+- **Version**: 1.1
+- **Status**: draft
 - **Severity**: medium
 
 ### 📘 Rule S022 – Escape data properly based on output context
+
 - **Objective**: Prevent XSS, Header Injection, Email Injection by escaping output data according to context (HTML, JS, URL, Header, Email, etc).
 - **Details**:
-    - Use the correct escaping strategy for each context:
-        - **HTML content**: escape `&`, `<`, `>`, `"`, `'`
-        - **HTML attributes**: escape `"` and `'` values
-        - **JavaScript inline**: escape strings to avoid arbitrary execution
-        - **URL params**: use `encodeURIComponent()`
-        - **HTTP headers**: strip `\r`, `\n` to prevent injection
-        - **SMTP email**: filter control characters like `\r`, `\n`, `bcc:` from content
-    - Avoid using a single escape function for all cases.
+  - Use the correct escaping strategy for each context:
+    - **HTML content**: escape `&`, `<`, `>`, `"`, `'`
+    - **HTML attributes**: escape `"` and `'` values
+    - **JavaScript inline**: escape strings to avoid arbitrary execution
+    - **URL params**: use `encodeURIComponent()`
+    - **HTTP headers**: strip `\r`, `\n` to prevent injection
+    - **SMTP email**: filter control characters like `\r`, `\n`, `bcc:` from content
+  - Avoid using a single escape function for all cases.
 - **Applies to**: All languages
 - **Tools**: ESLint (`no-script-url`, `react/no-danger`), Bandit, SonarQube (S2076), DOMPurify, Manual Review
 - **Principles**: CODE_QUALITY, SECURITY
@@ -366,15 +370,16 @@
 - **Severity**: medium
 
 ### 📘 Rule S023 – Prevent JSON Injection and JSON eval attacks
+
 - **Objective**: Prevent JavaScript execution via unsafe JSON handling or injection attacks.
 - **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.
+  - 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.
 - **Applies to**: All languages
 - **Tools**: ESLint (`no-eval`), Semgrep (`eval-dynamic`, `json-injection`), Bandit, SonarQube (S1523), Manual Review
 - **Principles**: CODE_QUALITY, SECURITY
@@ -383,34 +388,36 @@
 - **Severity**: high
 
 ### 📘 Rule S024 – Protect against XPath Injection and XML External Entity (XXE)
+
 - **Objective**: Prevent XPath injection and XXE vulnerabilities that can expose files, trigger SSRF, or run malicious code.
 - **Details**:
-    - **XPath Injection**:
-        - Never inject user data directly into XPath queries.
-        - Use parameterized APIs or safe XPath binding mechanisms.
-    - **XXE**:
-        - Disable external entity processing in XML parsers to prevent local file access or SSRF.
-        - Disable general and parameter entity processing in DOM/SAX/lxml parsers.
+  - **XPath Injection**:
+    - Never inject user data directly into XPath queries.
+    - Use parameterized APIs or safe XPath binding mechanisms.
+  - **XXE**:
+    - Disable external entity processing in XML parsers to prevent local file access or SSRF.
+    - Disable general and parameter entity processing in DOM/SAX/lxml parsers.
 - **Applies to**: All languages
 - **Tools**: Semgrep (xpath injection), Bandit (Python), SonarQube (S2755), Manual Config Review
 - **Principles**: SECURITY
-- **Version**:
-- **Status**: draft
+- **Version**: 1.1
+- **Status**: activated
 - **Severity**: medium
 
 ### 📘 Rule S025 – Always validate client-side data on the server
+
 - **Objective**: Ensure all data from clients is validated server-side to prevent attacks from forged or malicious input.
 - **Details**:
-    - Client-side validation is only for UX – it can be bypassed.
-    - Server-side validation is the last defense before DB writes or API calls.
-    - Benefits:
-        - Blocks SQLi, XSS, Buffer Overflow, SSRF
-        - Preserves data integrity (valid enums, length limits, etc.)
-        - Testable via unit tests
-    - Recommended libraries:
-        - Java: Hibernate Validator, Spring `@Valid`
-        - Node.js: Joi, express-validator
-        - Python: pydantic, marshmallow
+  - Client-side validation is only for UX – it can be bypassed.
+  - Server-side validation is the last defense before DB writes or API calls.
+  - Benefits:
+    - Blocks SQLi, XSS, Buffer Overflow, SSRF
+    - Preserves data integrity (valid enums, length limits, etc.)
+    - Testable via unit tests
+  - Recommended libraries:
+    - Java: Hibernate Validator, Spring `@Valid`
+    - Node.js: Joi, express-validator
+    - Python: pydantic, marshmallow
 - **Applies to**: All languages
 - **Tools**: SonarQube (S5334), ESLint (`require-validate`), Bandit (Python), Static Analysis
 - **Principles**: CODE_QUALITY, SECURITY
@@ -419,18 +426,19 @@
 - **Severity**: medium
 
 ### 📘 Rule S026 – Apply JSON Schema Validation to input data
+
 - **Objective**: Ensure all incoming JSON is fully validated by schema (structure, types, constraints) before processing.
 - **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`
+  - 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`
 - **Applies to**: All languages
 - **Tools**: AJV, jsonschema, Joi, Pydantic, Hibernate Validator, SonarQube (custom rule), Manual Review
 - **Principles**: CODE_QUALITY, SECURITY
@@ -439,18 +447,19 @@
 - **Severity**: medium
 
 ### 📘 Rule S027 – Never expose secrets in source code or Git
+
 - **Objective**: Prevent leakage of credentials, API keys, tokens, or sensitive config via source code or version control.
 - **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)
+  - 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)
 - **Applies to**: All languages
 - **Tools**: GitLeaks, TruffleHog, detect-secrets, git-secrets, SonarQube (custom rule)
 - **Principles**: CODE_QUALITY, SECURITY
@@ -459,21 +468,22 @@
 - **Severity**: medium
 
 ### 📘 Rule S028 – Limit upload file size and number of files per user
+
 - **Objective**: Prevent resource abuse and protect against DoS attacks by limiting file size, number of files, and user storage usage.
 - **Details**:
-    - Must enforce limits on:
-        - **Maximum file size** (e.g., ≤ 10MB)
-        - **Total number of files** per user or per upload
-        - **Total storage quota per user** (if applicable)
-    - Limits should be:
-        - Enforced on both client-side and server-side (server is mandatory)
-        - Handled via HTTP layer or upload middleware
-        - Logged when violations occur for abuse tracking
-    - Technology examples:
-        - Node.js: `multer` (`limits.fileSize`, `fileFilter`)
-        - Python: `Flask-Limiter`, request body size limit
-        - Java: Spring's `multipart.maxFileSize`, `maxRequestSize`
-        - Nginx/nginx-ingress: `client_max_body_size`
+  - Must enforce limits on:
+    - **Maximum file size** (e.g., ≤ 10MB)
+    - **Total number of files** per user or per upload
+    - **Total storage quota per user** (if applicable)
+  - Limits should be:
+    - Enforced on both client-side and server-side (server is mandatory)
+    - Handled via HTTP layer or upload middleware
+    - Logged when violations occur for abuse tracking
+  - Technology examples:
+    - Node.js: `multer` (`limits.fileSize`, `fileFilter`)
+    - Python: `Flask-Limiter`, request body size limit
+    - Java: Spring's `multipart.maxFileSize`, `maxRequestSize`
+    - Nginx/nginx-ingress: `client_max_body_size`
 - **Applies to**: All languages
 - **Tools**: Manual Review, Static Analysis, API Gateway Limit, Nginx Config, WAF, SonarQube (custom rule)
 - **Principles**: CODE_QUALITY, SECURITY
@@ -482,21 +492,22 @@
 - **Severity**: medium
 
 ### 📘 Rule S029 – Apply CSRF protection for authentication-related features
+
 - **Objective**: Prevent Cross-Site Request Forgery (CSRF) attacks where an attacker triggers unauthorized actions using the victim's authenticated session.
 - **Details**:
-    - CSRF occurs when:
-        - Victim is logged in (cookies exist)
-        - Browser automatically sends cookies with attacker-forged requests
-    - **Protection mechanisms**:
-        - **CSRF Token**: Generate a unique token (per session/request), attach it in form or header, and validate server-side
-        - **SameSite Cookie**:
-            - `SameSite=Lax`: suitable for most form-based POST requests
-            - `SameSite=Strict`: most secure, may affect UX
-            - `SameSite=None; Secure`: required for cross-domain cookies (must use HTTPS)
-        - **2FA or re-authentication** for critical actions like changing email/password or performing transactions
-    - For API or SPA:
-        - Avoid storing access tokens in cookies
-        - Prefer using `Authorization: Bearer <token>` to eliminate CSRF risk
+  - CSRF occurs when:
+    - Victim is logged in (cookies exist)
+    - Browser automatically sends cookies with attacker-forged requests
+  - **Protection mechanisms**:
+    - **CSRF Token**: Generate a unique token (per session/request), attach it in form or header, and validate server-side
+    - **SameSite Cookie**:
+      - `SameSite=Lax`: suitable for most form-based POST requests
+      - `SameSite=Strict`: most secure, may affect UX
+      - `SameSite=None; Secure`: required for cross-domain cookies (must use HTTPS)
+    - **2FA or re-authentication** for critical actions like changing email/password or performing transactions
+  - For API or SPA:
+    - Avoid storing access tokens in cookies
+    - Prefer using `Authorization: Bearer <token>` to eliminate CSRF risk
 - **Applies to**: All languages
 - **Tools**: Spring Security CSRF, Express `csurf`, Django CSRF middleware, Helmet.js, Manual Review, SonarQube (custom rule)
 - **Principles**: CODE_QUALITY, SECURITY
@@ -505,18 +516,19 @@
 - **Severity**: high
 
 ### 📘 Rule S030 – Disable directory browsing and protect sensitive metadata files
+
 - **Objective**: Prevent unauthorized access to file listings or metadata files such as `.git`, `.env`, `.DS_Store`, which can reveal sensitive system or source code information.
 - **Details**:
-    - Directory browsing occurs if no `index.html` exists or misconfigured server
-    - Sensitive files may be exposed if not explicitly blocked, e.g.:
-        - `.git/config` → contains repo URL or credentials
-        - `.env` → secrets
-        - `.DS_Store`, `Thumbs.db`, `.svn` → folder structure leaks
-    - **Mitigation**:
-        - Disable `autoindex` or `Indexes` on the web server (Apache/Nginx)
-        - Deny access to metadata or dotfiles (`.git`, `.env`, etc.)
-        - Review default config of frameworks (Express, Spring, Django, etc.)
-        - Use `.gitignore` to exclude sensitive files from version control
+  - Directory browsing occurs if no `index.html` exists or misconfigured server
+  - Sensitive files may be exposed if not explicitly blocked, e.g.:
+    - `.git/config` → contains repo URL or credentials
+    - `.env` → secrets
+    - `.DS_Store`, `Thumbs.db`, `.svn` → folder structure leaks
+  - **Mitigation**:
+    - Disable `autoindex` or `Indexes` on the web server (Apache/Nginx)
+    - Deny access to metadata or dotfiles (`.git`, `.env`, etc.)
+    - Review default config of frameworks (Express, Spring, Django, etc.)
+    - Use `.gitignore` to exclude sensitive files from version control
 - **Applies to**: All languages
 - **Tools**: Static Analysis, Manual Review, Burp Suite, Nikto, SonarQube (custom rule)
 - **Principles**: CODE_QUALITY, SECURITY
@@ -525,17 +537,18 @@
 - **Severity**: medium
 
 ### 📘 Rule S031 – Set the Secure flag on session cookies for HTTPS protection
+
 - **Objective**: Prevent attackers from stealing session cookies via unencrypted HTTP, especially on public or monitored networks (MITM).
 - **Details**:
-    - If a **cookie lacks the `Secure` flag**, it may be sent over plain HTTP
-    - Attackers on public Wi-Fi or LAN may intercept session tokens
-    - Sensitive cookies should always include:
-        - `Secure`: only send via HTTPS
-        - `HttpOnly`: prevent JS access
-        - `SameSite`: control CSRF exposure
-    - **Best practices**:
-        - Use HTTPS in all environments (dev, staging, prod)
-        - Ensure web server enforces HTTP → HTTPS redirects
+  - If a **cookie lacks the `Secure` flag**, it may be sent over plain HTTP
+  - Attackers on public Wi-Fi or LAN may intercept session tokens
+  - Sensitive cookies should always include:
+    - `Secure`: only send via HTTPS
+    - `HttpOnly`: prevent JS access
+    - `SameSite`: control CSRF exposure
+  - **Best practices**:
+    - Use HTTPS in all environments (dev, staging, prod)
+    - Ensure web server enforces HTTP → HTTPS redirects
 - **Applies to**: All languages
 - **Tools**: OWASP ZAP, Burp Suite, Static Analysis, Manual Review, SonarQube (custom rule)
 - **Principles**: SECURITY
@@ -586,20 +599,20 @@
 
 - **Objective**: Prevent cookie theft between subdomains (e.g., `api.example.com` accessing cookies from `admin.example.com`) by using cookies prefixed with `__Host-`, which enforce strict security tied to the root domain.
 - **Details**:
-    - The `__Host-` prefix enforces:
-        - Must include `Secure`
-        - Must not specify `Domain` (defaults to root domain)
-        - `Path` must be `/`
-    - Advantages:
-        - Cookie exists only on the root domain (e.g., `example.com`), cannot be overridden by subdomains.
-        - Prevents scenarios like:
-            - A malicious app on `sub1.example.com` sets a fake `sessionId`, which is then reused on `example.com`.
-    - Commonly used for:
-        - Session cookies
-        - CSRF tokens
-        - Auth tokens
-    - Limitation:
-        - Only applicable over **HTTPS** and must be set from the root domain.
+  - The `__Host-` prefix enforces:
+    - Must include `Secure`
+    - Must not specify `Domain` (defaults to root domain)
+    - `Path` must be `/`
+  - Advantages:
+    - Cookie exists only on the root domain (e.g., `example.com`), cannot be overridden by subdomains.
+    - Prevents scenarios like:
+      - A malicious app on `sub1.example.com` sets a fake `sessionId`, which is then reused on `example.com`.
+  - Commonly used for:
+    - Session cookies
+    - CSRF tokens
+    - Auth tokens
+  - Limitation:
+    - Only applicable over **HTTPS** and must be set from the root domain.
 - **Applies to**: All languages
 - **Tools**: Manual Review, Static Analysis, Chrome DevTools Audit, SonarQube (custom rule)
 - **Principles**: CODE_QUALITY, SECURITY
@@ -611,13 +624,13 @@
 
 - **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.
 - **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 `/`.
+  - 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 `/`.
 - **Applies to**: All languages
 - **Tools**: Static Analysis, Manual Review, Chrome DevTools, Postman, SonarQube (custom rule)
 - **Principles**: CODE_QUALITY, SECURITY
@@ -629,15 +642,15 @@
 
 - **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.
 - **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.
+  - **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.
 - **Applies to**: All languages
 - **Tools**: Static Analysis, OWASP ZAP, Burp Suite, Manual Review, SonarQube (custom rule)
 - **Principles**: CODE_QUALITY, SECURITY
@@ -649,18 +662,18 @@
 
 - **Objective**: Prevent browsers from caching sensitive data such as tokens, personal information, or financial content which could leak when users share devices or use back/forward navigation.
 - **Details**:
-    - Modern browsers may cache:
-        - Filled-in forms
-        - Login results
-        - Rendered tokens or confidential data
-    - Recommended headers:
-        - `Cache-Control: no-store, no-cache, must-revalidate`
-        - `Pragma: no-cache`
-        - `Expires: 0`
-    - Use for:
-        - Profile lookups, dashboard pages
-        - Tokens, session content
-    - Check using DevTools → Network → Headers.
+  - Modern browsers may cache:
+    - Filled-in forms
+    - Login results
+    - Rendered tokens or confidential data
+  - Recommended headers:
+    - `Cache-Control: no-store, no-cache, must-revalidate`
+    - `Pragma: no-cache`
+    - `Expires: 0`
+  - Use for:
+    - Profile lookups, dashboard pages
+    - Tokens, session content
+  - Check using DevTools → Network → Headers.
 - **Applies to**: All languages
 - **Tools**: Static Analysis, Postman, Chrome DevTools, Manual Review, SonarQube (custom rule)
 - **Principles**: SECURITY
@@ -672,32 +685,32 @@
 
 - **Objective**: Prevent attackers from discovering backend technologies (e.g., server, framework, OS) via HTTP response headers that can be used to target known vulnerabilities.
 - **Details**:
-    - Common leak examples:
-        - `Server: nginx/1.23.0`
-        - `X-Powered-By: Express`
-        - `X-AspNet-Version`, `X-Runtime`, etc.
-    - Preventive steps:
-        - Disable or override these headers.
-        - Use middleware or reverse proxy to strip response headers.
-        - Verify using DevTools, curl, or Postman.
+  - Common leak examples:
+    - `Server: nginx/1.23.0`
+    - `X-Powered-By: Express`
+    - `X-AspNet-Version`, `X-Runtime`, etc.
+  - Preventive steps:
+    - Disable or override these headers.
+    - Use middleware or reverse proxy to strip response headers.
+    - Verify using DevTools, curl, or Postman.
 - **Applies to**: All languages
 - **Tools**: Static Analysis, curl, Postman, Chrome DevTools, Burp Suite, SonarQube (custom rule)
 - **Principles**: SECURITY
-- **Version**:
-- **Status**: draft
+- **Version**: 1.1
+- **Status**: activated
 - **Severity**: medium
 
 ### 📘 Rule S039 – Never transmit Session Tokens via URL parameters
 
 - **Objective**: Prevent session hijacking by ensuring session tokens are not stored in browser history, server logs, proxy logs, or leaked via Referrer headers.
 - **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
+  - 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
 - **Applies to**: All languages
 - **Tools**: Static Analysis, Manual Review, Burp Suite, Postman, SonarQube (custom rule)
 - **Principles**: SECURITY
@@ -709,34 +722,34 @@
 
 - **Objective**: Prevent attackers from setting a session ID before login and taking over the session post-login if the ID remains unchanged.
 - **Details**:
-    - Attack scenario:
-        - Attacker sets known session ID before login
-        - Victim logs in without regenerating session
-        - Attacker reuses the same ID for access
-    - Preventive actions:
-        - Invalidate old session after login and create a new one
-        - For JWT: issue new token on login
-        - For cookies: delete old session and set a new cookie
+  - Attack scenario:
+    - Attacker sets known session ID before login
+    - Victim logs in without regenerating session
+    - Attacker reuses the same ID for access
+  - Preventive actions:
+    - Invalidate old session after login and create a new one
+    - For JWT: issue new token on login
+    - For cookies: delete old session and set a new cookie
 - **Applies to**: All languages
 - **Tools**: Static Analysis, Manual Review, OWASP ZAP, Burp Suite, SonarQube (custom rule)
 - **Principles**: SECURITY
-- **Version**: 1.0
-- **Status**: activated
+- **Version**: 1.1
+- **Status**: draft
 - **Severity**: high
 
 ### 📘 Rule S041 – Session Tokens must be invalidated after logout or expiration
 
 - **Objective**: Prevent users from reusing old session tokens after logout or timeout, which could lead to session hijacking.
 - **Details**:
-    - Actions required:
-        - **Backend**:
-            - Remove session from memory (e.g., Redis)
-            - Revoke token or blacklist old JWT
-        - **Frontend**:
-            - Delete cookie (`document.cookie = ...`, `res.clearCookie(...)`)
-            - Remove tokens from localStorage
-            - Redirect/reload after logout
-    - Add `Cache-Control: no-store` to prevent old content reuse
+  - Actions required:
+    - **Backend**:
+      - Remove session from memory (e.g., Redis)
+      - Revoke token or blacklist old JWT
+    - **Frontend**:
+      - Delete cookie (`document.cookie = ...`, `res.clearCookie(...)`)
+      - Remove tokens from localStorage
+      - Redirect/reload after logout
+  - Add `Cache-Control: no-store` to prevent old content reuse
 - **Applies to**: All languages
 - **Tools**: Static Analysis, Manual Review, Postman, DevTools, SonarQube (custom rule)
 - **Principles**: CODE_QUALITY, SECURITY
@@ -748,12 +761,12 @@
 
 - **Objective**: Reduce the risk of session hijacking or privilege misuse by forcing re-authentication after long idle periods or before critical actions.
 - **Details**:
-    - When using persistent login or "Remember Me":
-        - Require re-login after X hours (e.g., 12h, 24h)
-        - Re-authenticate after inactivity (e.g., 30 mins)
-        - Require password or 2FA for sensitive actions (password change, payments)
-    - For JWT:
-        - Use short-lived tokens with secure refresh logic
+  - When using persistent login or "Remember Me":
+    - Require re-login after X hours (e.g., 12h, 24h)
+    - Re-authenticate after inactivity (e.g., 30 mins)
+    - Require password or 2FA for sensitive actions (password change, payments)
+  - For JWT:
+    - Use short-lived tokens with secure refresh logic
 - **Applies to**: All languages
 - **Tools**: Manual Review, Static Analysis (JWT expiry, session policy), Security Test, SonarQube (custom rule)
 - **Principles**: CODE_QUALITY, SECURITY
@@ -765,27 +778,27 @@
 
 - **Objective**: Ensure attackers cannot continue using old session tokens after a password change. Enforce correct access control after sensitive updates.
 - **Details**:
-    - On password change:
-        - Invalidate all other active sessions (except current if necessary)
-        - Clear all session tokens from DB, Redis, or memory
-        - For JWT: use token versioning or timestamp to revoke old tokens
-        - Require re-login across all devices
+  - On password change:
+    - Invalidate all other active sessions (except current if necessary)
+    - Clear all session tokens from DB, Redis, or memory
+    - For JWT: use token versioning or timestamp to revoke old tokens
+    - Require re-login across all devices
 - **Applies to**: All languages
 - **Tools**: Manual Review, Static Analysis (Token Revocation Logic), SonarQube (custom rule)
 - **Principles**: CODE_QUALITY, SECURITY
-- **Version**: 1.0
-- **Status**: activated
+- **Version**: 1.1
+- **Status**: draft
 - **Severity**: medium
 
 ### 📘 Rule S044 – Require re-authentication before modifying critical information
 
 - **Objective**: Prevent unauthorized changes to critical information when the session is not fully authenticated. Protect users in half-open session states.
 - **Details**:
-    - When updating sensitive information (password, email, payment method, access permissions, etc.):
-        - Require password re-entry or two-factor authentication (2FA)
-        - Do not store any information in session unless fully authenticated
-        - If the session is in a temporary state (e.g., OTP not completed or social login not finished), **block access to sensitive resources**
-    - On the frontend: redirect the user to the re-authentication screen
+  - When updating sensitive information (password, email, payment method, access permissions, etc.):
+    - Require password re-entry or two-factor authentication (2FA)
+    - Do not store any information in session unless fully authenticated
+    - If the session is in a temporary state (e.g., OTP not completed or social login not finished), **block access to sensitive resources**
+  - On the frontend: redirect the user to the re-authentication screen
 - **Applies to**: All languages
 - **Tools**: Manual Review, Static Analysis (flow check), Security Test, SonarQube (custom rule)
 - **Principles**: CODE_QUALITY, SECURITY
@@ -797,12 +810,12 @@
 
 - **Objective**: Prevent brute-force and credential stuffing attacks by limiting failed login attempts and introducing friction for suspicious behavior.
 - **Details**:
-    - Implement one or more of the following:
-        - Limit failed login attempts by IP or account (Rate Limiting)
-        - Soft lockout: temporarily lock account (e.g., 15 minutes after 5 failed attempts)
-        - Trigger CAPTCHA or 2FA after multiple failed attempts
-        - Check passwords against breached password lists (e.g., HaveIBeenPwned, zxcvbn)
-    - Log all failed login attempts for monitoring and alerting
+  - Implement one or more of the following:
+    - Limit failed login attempts by IP or account (Rate Limiting)
+    - Soft lockout: temporarily lock account (e.g., 15 minutes after 5 failed attempts)
+    - Trigger CAPTCHA or 2FA after multiple failed attempts
+    - Check passwords against breached password lists (e.g., HaveIBeenPwned, zxcvbn)
+  - Log all failed login attempts for monitoring and alerting
 - **Applies to**: All languages
 - **Tools**: Manual Review, Static Analysis, OWASP ZAP, Custom Logging, SonarQube (custom rule)
 - **Principles**: CODE_QUALITY, SECURITY
@@ -814,34 +827,34 @@
 
 - **Objective**: Alert users to sensitive actions to detect potential compromise and allow timely intervention.
 - **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
+  - 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
 - **Applies to**: All languages
 - **Tools**: Manual Review, Security Test, Notification Audit, SonarQube (custom rule)
 - **Principles**: CODE_QUALITY, SECURITY
-- **Version**: 1.0
-- **Status**: activated
+- **Version**: 1.1
+- **Status**: draft
 - **Severity**: medium
 
 ### 📘 Rule S047 – Secure temporary passwords and activation codes
 
 - **Objective**: Ensure that temporary passwords and activation codes are secure, unpredictable, single-use, and time-limited.
 - **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
+  - 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
 - **Applies to**: All languages
 - **Tools**: Manual Review, Static Analysis, Audit Flow, SonarQube (custom rule)
 - **Principles**: CODE_QUALITY, SECURITY
@@ -853,12 +866,12 @@
 
 - **Objective**: Ensure the current user password is never revealed or sent in any step of the password reset process.
 - **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
+  - **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
 - **Applies to**: All languages
 - **Tools**: Manual Review, Penetration Test, SonarQube (custom rule)
 - **Principles**: SECURITY
@@ -870,12 +883,12 @@
 
 - **Objective**: Ensure that OTPs, reset tokens, and activation links expire quickly to reduce risk of interception or reuse.
 - **Details**:
-    - Authentication codes must:
-        - Expire quickly (⏱ recommended: **5–10 minutes**)
-        - Be **automatically invalidated** after expiration
-        - Be **one-time use only**
-    - Do not accept expired or reused codes
-    - For critical actions (reset password, email verification), require re-authentication after code validation
+  - Authentication codes must:
+    - Expire quickly (⏱ recommended: **5–10 minutes**)
+    - Be **automatically invalidated** after expiration
+    - Be **one-time use only**
+  - Do not accept expired or reused codes
+  - For critical actions (reset password, email verification), require re-authentication after code validation
 - **Applies to**: All languages
 - **Tools**: Manual Review, Static Analysis, SonarQube (custom rule)
 - **Principles**: CODE_QUALITY, SECURITY
@@ -887,16 +900,16 @@
 
 - **Objective**: Prevent attackers from predicting or forging session tokens by ensuring sufficient length, entropy, and cryptographic safety.
 - **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
+  - 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
 - **Applies to**: All languages
 - **Tools**: Manual Review, Static Analysis, SonarQube (custom rule)
 - **Principles**: CODE_QUALITY, SECURITY
@@ -908,12 +921,12 @@
 
 - **Objective**: Allow users to use strong passphrases while preventing resource abuse from excessively long inputs.
 - **Details**:
-    - Accept passwords with **12–64 characters**
-        - Support strong passphrases (e.g. `correct horse battery staple`)
-    - **Reject passwords >128 characters** to:
-        - Prevent DoS from large inputs
-        - Avoid poor hash performance on long strings
-    - Optionally warn users if password <12 characters
+  - Accept passwords with **12–64 characters**
+    - Support strong passphrases (e.g. `correct horse battery staple`)
+  - **Reject passwords >128 characters** to:
+    - Prevent DoS from large inputs
+    - Avoid poor hash performance on long strings
+  - Optionally warn users if password <12 characters
 - **Applies to**: All languages
 - **Tools**: Manual Review, Static Analysis, Unit Test, SonarQube (custom rule)
 - **Principles**: CODE_QUALITY, SECURITY
@@ -925,10 +938,10 @@
 
 - **Objective**: Ensure OTPs are strong enough to resist brute-force or statistical guessing attacks.
 - **Details**:
-    - OTP must have minimum **20-bit entropy**, equivalent to **6-digit random numbers** (`000000–999999`)
-    - Generate OTPs using **CSPRNG**
-    - Avoid using `Math.random()` or insecure generators
-    - Alphanumeric or longer OTPs increase entropy and are preferred
+  - OTP must have minimum **20-bit entropy**, equivalent to **6-digit random numbers** (`000000–999999`)
+  - Generate OTPs using **CSPRNG**
+  - Avoid using `Math.random()` or insecure generators
+  - Alphanumeric or longer OTPs increase entropy and are preferred
 - **Applies to**: All languages
 - **Tools**: Manual Review, Unit Test, Static Analysis, SonarQube (custom rule)
 - **Principles**: CODE_QUALITY, SECURITY
@@ -940,15 +953,15 @@
 
 - **Objective**: Ensure OTPs are secure against spoofing and replay attacks by using safe, standard algorithms.
 - **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)
+  - **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)
 - **Applies to**: All languages
 - **Tools**: Manual Review, Unit Test, Static Analysis, SonarQube (custom rule)
 - **Principles**: CODE_QUALITY, SECURITY
@@ -960,10 +973,10 @@
 
 - **Objective**: Prevent brute-force attacks and ensure traceability and accountability in auditing. Avoid predictable, shared accounts lacking identity association.
 - **Details**:
-    - Do not use default or common account names (e.g., admin, root, sa, test, guest, etc.).
-    - Each user must have a separate account with role-based access control.
-    - Force password change on first use or system initialization.
-    - The system must log all login attempts and resource access per specific user.
+  - Do not use default or common account names (e.g., admin, root, sa, test, guest, etc.).
+  - Each user must have a separate account with role-based access control.
+  - Force password change on first use or system initialization.
+  - The system must log all login attempts and resource access per specific user.
 - **Applies to**: All languages
 - **Tools**: Manual Review, CI Security Audit, IAM Policy Scan, SonarQube (custom rule)
 - **Principles**: CODE_QUALITY, SECURITY
@@ -975,10 +988,10 @@
 
 - **Objective**: Prevent attacks via malformed or improperly handled data by validating incoming data format (e.g., JSON, XML).
 - **Details**:
-    - REST services must check the Content-Type HTTP header to ensure data format matches expectations (e.g., `application/json`, `application/xml`).
-    - Reject requests with incorrect or unsupported Content-Type.
-    - Avoid processing `text/plain`, `multipart/form-data` unless explicitly required.
-    - Log rejected requests due to invalid Content-Type to detect attacks or client issues early.
+  - REST services must check the Content-Type HTTP header to ensure data format matches expectations (e.g., `application/json`, `application/xml`).
+  - Reject requests with incorrect or unsupported Content-Type.
+  - Avoid processing `text/plain`, `multipart/form-data` unless explicitly required.
+  - Log rejected requests due to invalid Content-Type to detect attacks or client issues early.
 - **Applies to**: All languages
 - **Tools**: Manual Review, API Gateway Config, Static Code Analysis (Semgrep), SonarQube (custom rule)
 - **Principles**: SECURITY
@@ -990,10 +1003,10 @@
 
 - **Objective**: Prevent attackers from injecting fake log entries that distort tracking or exploit log analysis systems.
 - **Details**:
-    - Do not log user input directly without sanitization.
-    - Escape special characters like: `\n`, `\r`, `%`, `\t`, `"`, `'`, `[`, `]`, etc.
-    - Use structured logging (e.g., JSON) to detect anomalies more easily.
-    - Avoid `string concatenation` when writing log entries with user input.
+  - Do not log user input directly without sanitization.
+  - Escape special characters like: `\n`, `\r`, `%`, `\t`, `"`, `'`, `[`, `]`, etc.
+  - Use structured logging (e.g., JSON) to detect anomalies more easily.
+  - Avoid `string concatenation` when writing log entries with user input.
 - **Applies to**: All languages
 - **Tools**: SonarQube, Semgrep, Manual Review
 - **Principles**: CODE_QUALITY, SECURITY
@@ -1005,10 +1018,10 @@
 
 - **Objective**: Ensure consistent, accurate log timestamps to support auditing, investigation, and cross-system comparison.
 - **Details**:
-    - Always use UTC timezone for logging to avoid issues with local offsets or daylight saving.
-    - Configure system time sync via NTP (Network Time Protocol).
-    - Verify all backends, logging middleware, and log collectors use standard formats (`ISO 8601`, `UTC`, `RFC3339`, etc.).
-    - Helps unify log data across services and regions.
+  - Always use UTC timezone for logging to avoid issues with local offsets or daylight saving.
+  - Configure system time sync via NTP (Network Time Protocol).
+  - Verify all backends, logging middleware, and log collectors use standard formats (`ISO 8601`, `UTC`, `RFC3339`, etc.).
+  - Helps unify log data across services and regions.
 - **Applies to**: All languages
 - **Tools**: Manual Review, Audit Logging Middleware, Centralized Logging Tools (ELK, Fluentd, Datadog), SonarQube (custom rule)
 - **Principles**: CODE_QUALITY, SECURITY
@@ -1020,16 +1033,16 @@
 
 - **Objective**: Prevent Server-Side Request Forgery (SSRF) and protect internal networks or cloud metadata services from unauthorized access via untrusted input.
 - **Details**:
-    - Always validate URLs or network addresses from client input or HTTP metadata.
-    - Apply allow lists for:
-        - Valid protocols: only allow `https`, `http`
-        - Specific domains or trusted internal IP ranges
-        - Allowed ports (avoid sensitive ones like 22, 3306, 6379, etc.)
-    - Block access to:
-        - `127.0.0.1`, `::1` (localhost)
-        - `169.254.169.254` (AWS metadata)
-        - `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16` if not needed
-    - Limit timeouts and disallow redirects unless required.
+  - Always validate URLs or network addresses from client input or HTTP metadata.
+  - Apply allow lists for:
+    - Valid protocols: only allow `https`, `http`
+    - Specific domains or trusted internal IP ranges
+    - Allowed ports (avoid sensitive ones like 22, 3306, 6379, etc.)
+  - Block access to:
+    - `127.0.0.1`, `::1` (localhost)
+    - `169.254.169.254` (AWS metadata)
+    - `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16` if not needed
+  - Limit timeouts and disallow redirects unless required.
 - **Applies to**: All languages
 - **Tools**: SonarQube, Manual Review, Burp Suite Test
 - **Principles**: SECURITY
@@ -1041,15 +1054,15 @@
 
 - **Objective**: Reduce risks from the server making outbound requests to untrusted systems (SSRF, malicious downloads, data leaks).
 - **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.
+  - 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.
 - **Applies to**: All languages
 - **Tools**: Manual Config Review, Firewall/Proxy Logs, CloudTrail, Burp Suite Test, SonarQube (custom rule)
 - **Principles**: SECURITY
-- **Version**: 1.0
-- **Status**: activated
+- **Version**: 1.1
+- **Status**: draft
 - **Severity**: low