Feat/issue 2768 s2s auth policy

BackEnd/src/modules/webhooks/webhooks.controller.spec.ts

@@ -10,6 +10,9 @@ import { TraceService } from '../trace/trace.service';
 import { FailedWebhookStatus } from './entities/failed-webhook-event.entity';
 import { WebhookEventType, WebhookPayloadDto } from './dto/webhook-event.dto';
 
+import { WebhookEventType } from './dto/webhook-event.dto';
+
+
 /**
  * Unit tests for WebhooksController.
  *

BackEnd/src/modules/webhooks/webhooks.controller.ts

@@ -507,6 +507,36 @@ export class WebhooksController {
    * Generate unique event ID
    */
   private generateEventId(): string {
+
+    return `evt_${Date.now()}_${Math.random().toString(36).substr(2, 9)}`;
+  }
+
+  @Post('events')
+  @HttpCode(HttpStatus.OK)
+  @UsePipes(
+    new ValidationPipe({
+      whitelist: true,
+      forbidNonWhitelisted: true,
+      transform: true,
+    }),
+  )
+  async handleWebhook(@Body() payload: WebhookPayloadDto) {
+    return this.webhooksService.processEvent(payload);
+  }
+}
+
+
+@Post('events')
+  @HttpCode(HttpStatus.OK)
+  @UsePipes(
+    new ValidationPipe({
+      whitelist: true,
+      forbidNonWhitelisted: true,
+      transform: true,
+    }),
+  )
+  async handleWebhook(@Body() payload: WebhookPayloadDto) {
+    return this.webhooksService.processEvent(payload);
     return `evt_${Date.now()}_${Math.random().toString(36).substring(2, 11)}`;
   }
 }

governance/backend/CODING_STYLE_BE.md

@@ -0,0 +1,23 @@
+# Backend Coding-Style and Linting Governance
+
+## Overview
+This document defines the official coding-style, formatting, and static analysis (linting) standards for backend services in **EarnQuestOne/stellar_Earn**. Enforcing consistent code standards ensures high maintainability, reduces cognitive overhead, and prevents common runtime errors across microservices and Stellar blockchain integration modules.
+
+---
+
+## 1. Lint & Format Rules
+- **Language Standards**: All backend services (Node.js/TypeScript and Rust) must strictly adhere to the project's shared configuration files (`tsconfig.json`, `.eslintrc.json`, `prettier.config.js`, and `rustfmt.toml`).
+- **Formatting**: Automatic code formatting via Prettier or `rustfmt` is mandatory prior to committing code. Unformatted code will fail automated CI lint checks.
+- **Static Analysis**: ESLint and Clippy must report zero warnings and zero errors during CI builds. Disabling lint rules inline (e.g., via `eslint-disable` or `#[allow(...)]`) is strongly discouraged and requires explicit justification.
+
+---
+
+## 2. Exception & Rule Override Process
+- **Temporary Overrides**: If a specific line of code requires bypassing a lint or format rule, developers must use explicit, scoped suppression comments accompanied by a explanatory ticket reference (e.g., `// eslint-disable-next-line @typescript-eslint/no-explicit-any -- Required for dynamic JSON payload parsing in issue #...`).
+- **Permanent Rule Changes**: Proposals to modify shared lint rules or formatting presets must be submitted as an RFC or Pull Request targeting the root configuration files and require approval from core backend maintainers.
+
+---
+
+## 3. Ownership & Review Cadence
+- **Primary Owner**: Backend Engineering & Core Architecture Team.
+- **Review Cadence**: Audited annually or upon major runtime/language version upgrades.

governance/backend/CORS_POLICY.md

@@ -0,0 +1,26 @@
+# Backend CORS Policy Governance
+
+## Overview
+This document defines the official Cross-Origin Resource Sharing (CORS) policy governance for backend services in **EarnQuestOne/stellar_Earn**. Restricting permitted origins and HTTP methods prevents unauthorized cross-domain requests, cross-site request forgery (CSRF), and unauthorized API access across Stellar blockchain endpoints and backend services.
+
+---
+
+## 1. Allowed Origins & Environment Configuration
+- **Production Environment**: Only explicitly whitelisted, secure domains (`https://*.stellar-earn.com` or designated partner origins) are permitted. Wildcard origins (`*`) are strictly prohibited in production settings.
+- **Staging & Development**: Local development origins (e.g., `http://localhost:3000`, `http://127.0.0.1:5173`) are permitted only in non-production environment profiles.
+- **Allowed Methods & Headers**:
+  - Permitted HTTP Methods: `GET`, `POST`, `PUT`, `PATCH`, `DELETE`, `OPTIONS`.
+  - Permitted Headers: `Content-Type`, `Authorization`, `X-Correlation-ID`, `X-Requested-With`.
+  - Credentials Support: `Access-Control-Allow-Credentials: true` is enabled strictly for whitelisted trusted origins requiring session cookies or credentials.
+
+---
+
+## 2. Review and Change Approval Process
+- **Change Request Protocol**: Any addition or modification to the allowed origins list must be submitted via a pull request modifying the environment configurations and security gateway setup.
+- **Security Assessment**: CORS modification pull requests require mandatory review and approval from the Security Engineering lead to prevent unintended exposure of internal API endpoints.
+
+---
+
+## 3. Ownership & Review Cadence
+- **Primary Owner**: Security Engineering & Platform Infrastructure Team.
+- **Review Cadence**: Audited semi-annually or whenever new frontend applications or external partner integrations are added to the ecosystem.

governance/backend/S2S_AUTH.md

@@ -0,0 +1,31 @@
+# Backend Service-to-Service Authentication Policy
+
+## Overview
+This document defines the official Service-to-Service (S2S) authentication and authorization policy for backend microservices, background workers, and Stellar blockchain indexing daemons in **EarnQuestOne/stellar_Earn**. Securing internal service communication prevents lateral movement and unauthorized inter-service RPC executions.
+
+---
+
+## 1. Internal Authentication Architecture
+- **Mutual TLS (mTLS)**: All inter-service network traffic across internal networks or service meshes must be encrypted in transit using mTLS with strict X.509 certificate validation.
+- **Service Identity Tokens (JWT)**:
+  - Calling services must authenticate HTTP/gRPC requests using short-lived (maximum 15-minute validity) JSON Web Tokens (JWTs).
+  - Tokens must be signed asynchronously using RS256/EdDSA private keys held by the issuing identity service and verified via public key endpoint discovery (JWKS).
+  - Claims must include `iss` (calling service ID), `aud` (receiving service ID), and granular `scopes` declaring authorized operations.
+
+---
+
+## 2. Token Scope & Least Privilege
+- **Scoped Permissions**: Receiving services must validate that incoming S2S tokens possess the exact scope required for the requested endpoint (e.g., `scope: "ledger:read"`).
+- **No Pass-Through User Credentials**: S2S calls MUST NOT forward raw user sessions or tokens directly; user identity context must be explicitly passed in dedicated header fields (`X-User-Context`) alongside a valid S2S identity token.
+
+---
+
+## 3. Secret & Certificate Rotation
+- **Certificate Renewal**: Internal mTLS certificates must be automatically rotated via service mesh / Vault integrations at least every 30 days.
+- **JWKS Signing Key Rotation**: Keypairs used for signing S2S JWTs must undergo automated rotation every 90 days without requiring service restarts.
+
+---
+
+## 4. Ownership & Review Cadence
+- **Primary Owner**: Platform Infrastructure & Security Engineering Team.
+- **Review Cadence**: Audited semi-annually or upon significant topology changes to internal microservices.