forge-server 0.1.0

package/plugin/skills/security-audit/SKILL.md

@@ -0,0 +1,362 @@
+---
+name: security-audit
+description: This skill should be used when reviewing code for security vulnerabilities, conducting security audits, or implementing security-sensitive features like authentication, authorization, or data handling. Used by the inspector and platform-engineer agents.
+user-invocable: false
+---
+
+# Security Audit Skill
+
+## Purpose
+
+Provide a comprehensive, structured methodology for identifying and remediating security vulnerabilities in NestJS/React applications running on AWS/Kubernetes infrastructure. Apply this skill when reviewing code for security issues, implementing authentication or authorization features, handling sensitive data, configuring infrastructure access, or conducting periodic security audits. The methodology is adapted from the OWASP Top 10 and tailored to the specific technology stack and deployment patterns used in this organization.
+
+---
+
+## OWASP Top 10: Stack-Specific Checklist
+
+### 1. Injection
+
+**Threat**: Malicious input is interpreted as code or query syntax, allowing attackers to execute unauthorized operations.
+
+**SQL Injection**: Drizzle ORM uses parameterized queries by default. Direct string concatenation into SQL is the primary risk vector. Verify that:
+
+- No raw SQL queries contain string interpolation or concatenation with user input.
+- All user-supplied values pass through Drizzle's query builder or parameterized `sql` template literals.
+- Dynamic table or column names (if any) are validated against a whitelist, not interpolated.
+
+**Command Injection**: Never pass user input to shell execution functions (`exec`, `spawn`, `execSync`). If shell commands are absolutely necessary, use `execFile` with an argument array (not a command string) and validate every argument against an explicit whitelist.
+
+**NoSQL Injection**: If any NoSQL datastores are in use (Redis commands, Elasticsearch queries), verify that user input is not directly embedded in query objects. Use builder patterns or parameterized queries.
+
+**Template Injection**: Verify that server-side template rendering (if any) does not embed user input without escaping.
+
+### 2. Broken Authentication
+
+**JWT Validation**: Verify that every JWT validation checks:
+
+- **Signature**: The token is signed by the expected key (JWKS endpoint or shared secret).
+- **Expiration**: The `exp` claim is validated and expired tokens are rejected.
+- **Issuer**: The `iss` claim matches the expected identity provider.
+- **Audience**: The `aud` claim matches the application's expected audience.
+- **Not-before**: The `nbf` claim is respected if present.
+
+**Token Handling**: Verify that:
+
+- Tokens are not logged (not even in debug mode).
+- Tokens are transmitted only over HTTPS.
+- Refresh token rotation is implemented (each refresh token is single-use).
+- Token storage on the frontend uses httpOnly, secure, sameSite cookies — not localStorage.
+
+**Password Handling** (if applicable): Verify that:
+
+- Passwords are hashed with bcrypt (cost factor >= 12) or argon2.
+- Plaintext passwords are never stored, logged, or returned in API responses.
+- Password reset tokens are single-use and time-limited.
+
+### 3. Sensitive Data Exposure
+
+**Secrets in Code**: Scan for:
+
+- API keys, tokens, or passwords hardcoded in source files.
+- Secrets in configuration files committed to version control.
+- Secrets in Docker images (build args, env statements in Dockerfiles).
+- Secrets in log output (even debug-level logs).
+
+**Encryption**:
+
+- Data in transit: all communications must use TLS. Verify that internal service-to-service calls also use TLS or are within an encrypted network mesh.
+- Data at rest: sensitive database columns (PII, financial data) should use application-level or database-level encryption. Verify that RDS instances use encrypted storage.
+
+**CORS Configuration**: Verify that:
+
+- CORS origin is an explicit whitelist of allowed domains, not `*`.
+- CORS credentials mode is enabled only for whitelisted origins.
+- CORS methods are restricted to the methods actually used.
+
+### 4. XML External Entities (XXE)
+
+Not a primary concern in Node.js/React applications. However, if any XML parsing occurs (file uploads, SAML integration, third-party API responses), verify that:
+
+- External entity processing is disabled in the XML parser configuration.
+- DTD processing is disabled.
+- XML input size is limited.
+
+### 5. Broken Access Control
+
+**Authorization Checks**: Verify that every endpoint:
+
+- Requires authentication (unless explicitly marked as public with `@Public()`).
+- Performs authorization — not just "is the user authenticated?" but "does this user have permission to perform this action on this resource?"
+- Validates resource ownership: a user requesting `/users/123/documents` must be user 123, or must have admin/elevated permissions.
+
+**RBAC/ABAC Validation**: Verify that:
+
+- Role checks use NestJS guards, not inline if-statements in controllers.
+- Permission checks are consistent — the same action requires the same permission everywhere it appears.
+- Role hierarchies are enforced at the guard level, not assumed in business logic.
+
+**Direct Object Reference**: Verify that:
+
+- API endpoints do not expose sequential integer IDs that can be enumerated.
+- Resource access validates ownership/permission, not just existence.
+- Bulk endpoints (list, export) filter by the authenticated user's scope.
+
+### 6. Security Misconfiguration
+
+**HTTP Headers**: Verify that Helmet.js (or equivalent) is configured with:
+
+- `Content-Security-Policy`: restrict script sources, object sources, and frame ancestors.
+- `Strict-Transport-Security`: enforce HTTPS with a long max-age.
+- `X-Content-Type-Options: nosniff`: prevent MIME type sniffing.
+- `X-Frame-Options: DENY` (or `SAMEORIGIN` if iframing is required).
+- `Referrer-Policy: strict-origin-when-cross-origin` (or stricter).
+
+**Debug Mode**: Verify that:
+
+- NestJS detailed error responses (stack traces) are disabled in production.
+- Source maps are not served in production.
+- Swagger/OpenAPI documentation is disabled or auth-gated in production.
+
+**Default Credentials**: Verify that:
+
+- No default passwords exist in configuration, database seeds, or Docker compose files.
+- Database users have unique, strong passwords (sourced from Secrets Manager, not environment files).
+
+### 7. Cross-Site Scripting (XSS)
+
+**React Default Protection**: React escapes all interpolated values in JSX by default. The primary risk vectors are:
+
+- `dangerouslySetInnerHTML`: Every use must be reviewed. The input must be sanitized with a library like DOMPurify before rendering.
+- URL attributes (`href`, `src`, `action`): User-controlled URLs can contain `javascript:` protocol. Validate that URLs start with `https://` or a known safe protocol.
+- CSS injection: User-controlled values in `style` attributes can execute expressions in older browsers. Sanitize or whitelist.
+
+**Server-Side Rendering**: If SSR is used, verify that user input embedded in the HTML response is escaped properly. SSR bypasses React's JSX escaping for the initial render.
+
+### 8. Insecure Deserialization
+
+**Input Validation**: Verify that:
+
+- Every API endpoint uses NestJS `ValidationPipe` with `whitelist: true` and `forbidNonWhitelisted: true` — this strips unknown properties and rejects unexpected fields.
+- DTOs use `class-validator` decorators for all fields (type, length, format, range).
+- Nested objects in DTOs are validated with `@ValidateNested()` and `@Type()` decorators.
+- File uploads validate file type, size, and content (not just the extension).
+
+**JSON Parsing**: Verify that large JSON payloads are size-limited (NestJS body parser limit). Unbounded JSON parsing can be used for denial-of-service.
+
+### 9. Using Components with Known Vulnerabilities
+
+**Dependency Auditing**: Verify that:
+
+- `npm audit` reports no high or critical vulnerabilities. If vulnerabilities exist, they must be documented with a mitigation plan (upgrade, patch, or accept with justification).
+- Dependencies are updated regularly. Stale dependencies accumulate vulnerabilities.
+- No deprecated packages are in use without a documented migration plan.
+
+**Supply Chain**: Verify that:
+
+- Lock files (`package-lock.json`) are committed and used for deterministic installs.
+- No packages are installed from registries other than npm without explicit justification.
+- Pre/post-install scripts from third-party packages are reviewed.
+
+### 10. Insufficient Logging and Monitoring
+
+**Security Event Logging**: Verify that the following events are logged:
+
+- Authentication failures (failed login, invalid token, expired token).
+- Authorization failures (access denied, insufficient permissions).
+- Input validation failures (rejected requests with invalid data).
+- Administrative actions (user creation, role changes, permission grants).
+- Data access patterns (bulk exports, unusual query volumes).
+
+**Logging Hygiene**: Verify that logs never contain:
+
+- Passwords or password hashes.
+- Authentication tokens (JWT, API keys, session IDs).
+- Personally identifiable information (full SSN, credit card numbers, medical data).
+- Full request bodies for endpoints that accept sensitive data.
+
+**Log Format**: Use structured logging (JSON) with consistent fields: timestamp, level, requestId, userId, action, outcome. Unstructured string logs are difficult to search, alert on, and correlate.
+
+---
+
+## NestJS-Specific Security Patterns
+
+### Authentication Guards
+
+Use NestJS guards for authentication. Apply the guard globally and use `@Public()` decorator to opt out specific endpoints:
+
+```typescript
+// Apply globally in main.ts or app module
+app.useGlobalGuards(new JwtAuthGuard(reflector));
+
+// Opt out specific endpoints
+@Public()
+@Get('health')
+healthCheck() { return { status: 'ok' }; }
+```
+
+This is safer than applying guards per-controller — a forgotten guard on a new controller silently exposes an unauthenticated endpoint.
+
+### Authorization Decorators
+
+Create custom decorators for role-based access control:
+
+```typescript
+@Roles('admin', 'manager')
+@UseGuards(RolesGuard)
+@Delete(':id')
+async deleteUser(@Param('id') id: string) { ... }
+```
+
+The guard reads the metadata set by the decorator and validates against the authenticated user's roles. This keeps authorization logic in the guard (testable, centralized) and out of the controller (which should only handle HTTP concerns).
+
+### ValidationPipe Configuration
+
+Configure the global ValidationPipe to be strict:
+
+```typescript
+app.useGlobalPipes(new ValidationPipe({
+  whitelist: true,              // Strip properties not in the DTO
+  forbidNonWhitelisted: true,   // Reject requests with unknown properties
+  transform: true,              // Auto-transform payloads to DTO instances
+  transformOptions: {
+    enableImplicitConversion: false, // Require explicit type decorators
+  },
+}));
+```
+
+With `whitelist: true`, any property not decorated in the DTO is silently removed. With `forbidNonWhitelisted: true`, the request is rejected entirely. This prevents mass assignment attacks where extra properties (e.g., `isAdmin: true`) are injected into a request body.
+
+### Rate Limiting
+
+Apply rate limiting on public-facing and authentication endpoints using `@nestjs/throttler`:
+
+```typescript
+@UseGuards(ThrottlerGuard)
+@Throttle({ default: { limit: 5, ttl: 60000 } })  // 5 requests per minute
+@Post('login')
+async login(@Body() dto: LoginDto) { ... }
+```
+
+Rate limiting prevents brute-force attacks on login endpoints, credential stuffing, and API abuse. Apply stricter limits on authentication endpoints and more generous limits on read endpoints.
+
+---
+
+## Infrastructure Security
+
+### IAM Least Privilege
+
+All IAM roles and policies must be defined in the IaC repository (`aws-infrastructure`). Never create or modify IAM resources via the AWS CLI or console.
+
+Verify that:
+
+- Each service/pod has its own IAM role with only the permissions it needs.
+- No wildcard (`*`) actions in IAM policies unless absolutely necessary (and documented with justification).
+- No wildcard (`*`) resources unless the action genuinely applies to all resources (e.g., `logs:CreateLogGroup`).
+- Policies use resource-level permissions wherever the AWS service supports them.
+
+### IRSA (IAM Roles for Service Accounts)
+
+Verify that:
+
+- Each Kubernetes service account is bound to a specific IAM role via IRSA annotations.
+- The IAM role's trust policy restricts assumption to the specific namespace and service account: `system:serviceaccount:dk-synapse:dk-synapse-sa`.
+- No service account uses the node's IAM role (which grants overly broad permissions).
+
+### Secrets Management
+
+Verify that:
+
+- Application secrets (database credentials, API keys, encryption keys) are stored in AWS Secrets Manager.
+- Secrets are injected into pods via External Secrets Operator, not via Kubernetes Secrets defined in plain text.
+- No secrets appear in Helm values files, ConfigMaps, or container environment variable definitions in deployment manifests.
+- Secret rotation is configured for database credentials.
+
+### Network Policies
+
+Verify that:
+
+- Kubernetes NetworkPolicies restrict pod-to-pod communication to only the required paths.
+- Ingress is restricted to the ingress controller; pods do not accept traffic directly from external sources.
+- Egress is restricted to known destinations (database, external APIs, AWS services). Unrestricted egress allows data exfiltration.
+
+---
+
+## Code Review Security Checklist
+
+Use this quick-scan checklist for every code review. Each item takes seconds to verify but catches the most common security issues:
+
+- [ ] **No hardcoded secrets**: Search for API keys, tokens, passwords, connection strings in the diff. Check for strings that look like base64-encoded or hex-encoded secrets.
+- [ ] **All user input validated**: Every `@Body()`, `@Query()`, `@Param()` uses a DTO with class-validator decorators. No raw `any` types on request inputs.
+- [ ] **Auth checks on all protected endpoints**: New endpoints have `@UseGuards()` or are within a controller that has a global guard. Any `@Public()` decorator is intentional and justified.
+- [ ] **No sensitive data in logs**: Log statements do not include request bodies (which may contain passwords), authorization headers (which contain tokens), or PII.
+- [ ] **Dependencies checked**: If new dependencies are added, verify they are maintained, have no known critical vulnerabilities, and are necessary (not duplicating existing functionality).
+- [ ] **CORS unchanged or intentional**: If CORS configuration is modified, the change is reviewed explicitly. No accidental `origin: '*'`.
+- [ ] **Rate limiting on new public endpoints**: Any new public-facing endpoint (especially auth endpoints) has rate limiting configured.
+- [ ] **Error responses do not leak internals**: Catch blocks do not return stack traces, database error messages, or internal implementation details to the client. Production error responses use generic messages with a request ID for correlation.
+- [ ] **File uploads validated**: If the endpoint accepts file uploads, verify that file type, size, and content are validated. Files are stored with generated names (not user-supplied names) in a non-executable location.
+- [ ] **Database queries parameterized**: If raw SQL or dynamic queries are used, verify that user input is parameterized, not interpolated.
+
+---
+
+## Periodic Audit Procedure
+
+Conduct a full security audit at the following intervals and triggers:
+
+### Trigger-Based Audits
+
+- Before every production deployment of a new feature.
+- After adding a new third-party dependency.
+- After any change to authentication or authorization logic.
+- After any infrastructure change (IAM roles, network policies, secrets).
+
+### Periodic Audits (Monthly)
+
+1. **Dependency audit**: Run `npm audit`. Review and remediate all high and critical findings. Update stale dependencies.
+2. **Secret scan**: Search the codebase for hardcoded secrets using pattern matching (API key formats, base64 strings, common secret variable names).
+3. **Permission review**: Review IAM roles and Kubernetes RBAC. Remove permissions that are no longer needed. Verify that no new wildcard permissions have been added.
+4. **Log review**: Sample application logs for the past period. Verify that no sensitive data appears in logs. Verify that security events (auth failures, access denials) are being logged.
+5. **Access review**: Verify that all human access (AWS console, Kubernetes, database) follows least privilege. Deactivate access for team members who have left or changed roles.
+
+---
+
+## Common Vulnerability Patterns in This Stack
+
+### Unprotected Endpoint
+
+**Pattern**: A new controller is added without a guard, or an existing controller's guard is accidentally removed during refactoring.
+
+**Detection**: Search for controllers without `@UseGuards()` at the class or method level. Cross-reference with the global guard configuration — if a global guard is applied, verify that the controller does not accidentally bypass it.
+
+**Prevention**: Apply authentication guards globally. Use `@Public()` as an explicit opt-out rather than relying on opt-in.
+
+### Overly Permissive CORS
+
+**Pattern**: During development, CORS is set to `origin: '*'` for convenience. The wildcard configuration reaches production.
+
+**Detection**: Search for CORS configuration in `main.ts` or the app module. Verify that the origin is an explicit whitelist in production configuration.
+
+**Prevention**: Use environment-specific CORS configuration. The development config may use `'*'`; the production config must use an explicit domain list.
+
+### Token in URL
+
+**Pattern**: An API token or session ID is passed as a query parameter (`/api/data?token=xxx`). Query parameters are logged in access logs, cached by proxies, stored in browser history, and leaked via the Referer header.
+
+**Detection**: Search for `@Query()` parameters named `token`, `key`, `secret`, `auth`, or similar. Search for URL construction that appends tokens.
+
+**Prevention**: Transmit tokens in the `Authorization` header (for API tokens) or in httpOnly cookies (for session tokens). Never in URLs.
+
+### Mass Assignment
+
+**Pattern**: An API endpoint accepts a raw object type (or an overly permissive DTO) that allows the client to set fields that should be server-controlled (e.g., `isAdmin`, `role`, `createdBy`).
+
+**Detection**: Search for `@Body() body: any` or DTOs that include sensitive fields without `@Exclude()` or that lack `whitelist: true` in the ValidationPipe.
+
+**Prevention**: Use strict DTOs with only the fields the client is allowed to set. Apply `whitelist: true` to strip unknown properties. Never spread the raw body into a database insert without selecting specific fields.
+
+### Logging Sensitive Data
+
+**Pattern**: A debug log statement includes the full request body, which contains a password field. Or an error log includes the authorization header, which contains a JWT.
+
+**Detection**: Search for log statements that reference `req.body`, `req.headers`, `request.body`, `request.headers`, or that log entire objects (which may contain nested sensitive fields).
+
+**Prevention**: Log specific, non-sensitive fields. Use a structured logging approach where sensitive fields are redacted automatically. Never log `req.body` or `req.headers` directly.

package/plugin/skills/skill-development/.skillfish.json

@@ -0,0 +1,10 @@
+{
+  "version": 2,
+  "name": "skill-development",
+  "owner": "anthropics",
+  "repo": "claude-code",
+  "path": "plugins/plugin-dev/skills/skill-development",
+  "branch": "main",
+  "sha": "3dd57083301fd1ba1a4e04967c6fc055c6d740eb",
+  "source": "manual"
+}