diff --git a/BackEnd/src/modules/webhooks/webhooks.controller.spec.ts b/BackEnd/src/modules/webhooks/webhooks.controller.spec.ts index d6b0f792..7b08d4b1 100644 --- a/BackEnd/src/modules/webhooks/webhooks.controller.spec.ts +++ b/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. * diff --git a/BackEnd/src/modules/webhooks/webhooks.controller.ts b/BackEnd/src/modules/webhooks/webhooks.controller.ts index 8d331091..68db29d4 100644 --- a/BackEnd/src/modules/webhooks/webhooks.controller.ts +++ b/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)}`; } } diff --git a/governance/backend/CODING_STYLE_BE.md b/governance/backend/CODING_STYLE_BE.md new file mode 100644 index 00000000..43fb0db8 --- /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 diff --git a/governance/backend/CORS_POLICY.md b/governance/backend/CORS_POLICY.md new file mode 100644 index 00000000..46367de6 --- /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 diff --git a/governance/backend/S2S_AUTH.md b/governance/backend/S2S_AUTH.md new file mode 100644 index 00000000..e9a4c479 --- /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