From 8bddbc50a4449f073d214142ca6f29d8e2d9f505 Mon Sep 17 00:00:00 2001 From: mijinummi Date: Sat, 17 Oct 2026 14:11:11 +0100 Subject: [PATCH 1/3] docs(governance): add backend coding-style and linting governance policy and update index (#2757) --- .../webhooks/webhooks.controller.spec.ts | 3 +++ .../modules/webhooks/webhooks.controller.ts | 16 +++++++++++++ governance/backend/CODING_STYLE_BE.md | 23 +++++++++++++++++++ 3 files changed, 42 insertions(+) create mode 100644 governance/backend/CODING_STYLE_BE.md diff --git a/BackEnd/src/modules/webhooks/webhooks.controller.spec.ts b/BackEnd/src/modules/webhooks/webhooks.controller.spec.ts index 7da24d80f..8cf95ffc0 100644 --- a/BackEnd/src/modules/webhooks/webhooks.controller.spec.ts +++ b/BackEnd/src/modules/webhooks/webhooks.controller.spec.ts @@ -9,6 +9,9 @@ import { WebhooksService, WebhookResponse } from './webhooks.service'; import { TraceService } from '../trace/trace.service'; import { FailedWebhookStatus } from './entities/failed-webhook-event.entity'; +import { WebhookEventType } from './dto/webhook-event.dto'; + + /** * Unit tests for WebhooksController. * diff --git a/BackEnd/src/modules/webhooks/webhooks.controller.ts b/BackEnd/src/modules/webhooks/webhooks.controller.ts index 9b4090286..6b7564b11 100644 --- a/BackEnd/src/modules/webhooks/webhooks.controller.ts +++ b/BackEnd/src/modules/webhooks/webhooks.controller.ts @@ -13,6 +13,8 @@ import { Param, Query, UseGuards, + UsePipes, + ValidationPipe, } from '@nestjs/common'; import { ApiTags, @@ -489,8 +491,22 @@ export class WebhooksController { 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( diff --git a/governance/backend/CODING_STYLE_BE.md b/governance/backend/CODING_STYLE_BE.md new file mode 100644 index 000000000..43fb0db8a --- /dev/null +++ b/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. \ No newline at end of file From 8f33dd16d9765cab72adacf5a2115b3f6ab8bb6d Mon Sep 17 00:00:00 2001 From: mijinummi Date: Sat, 17 Oct 2026 14:12:21 +0100 Subject: [PATCH 2/3] docs(governance): add backend CORS policy governance and update governance index (#2769) --- governance/backend/CORS_POLICY.md | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) create mode 100644 governance/backend/CORS_POLICY.md diff --git a/governance/backend/CORS_POLICY.md b/governance/backend/CORS_POLICY.md new file mode 100644 index 000000000..46367de6a --- /dev/null +++ b/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. \ No newline at end of file From 7a7bb467881aa66dc0ba963b96d0b68f7722f121 Mon Sep 17 00:00:00 2001 From: mijinummi Date: Sat, 17 Oct 2026 14:12:56 +0100 Subject: [PATCH 3/3] docs(governance): add backend service-to-service auth policy and update index (#2768) --- governance/backend/S2S_AUTH.md | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) create mode 100644 governance/backend/S2S_AUTH.md diff --git a/governance/backend/S2S_AUTH.md b/governance/backend/S2S_AUTH.md new file mode 100644 index 000000000..e9a4c479a --- /dev/null +++ b/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. \ No newline at end of file