fix build image error
This commit is contained in:
root
@@ -0,0 +1,160 @@
|
||||
# Security Hardening Application Report
|
||||
|
||||
Generated: 2026-06-09
|
||||
Project: RentalDriveGo / Car Management System
|
||||
Input archive: `/mnt/data/car_management_system_plan_applied(1).zip`
|
||||
Plan applied: `/mnt/data/SECURITY_HARDENING_IMPLEMENTATION_PLAN(1).md`
|
||||
|
||||
## Executive result
|
||||
|
||||
The uploaded project was inspected and the security hardening plan was applied as far as safely possible inside the source archive. The archive already contained a broad previous hardening pass. I did not blindly trust that state, because that is how software becomes an expensive apology letter. I re-audited the implementation against the plan and applied additional corrections where the code still contradicted the target security model.
|
||||
|
||||
The final output includes a patched project archive, this report, a changed-file list, and an incremental diff for the additional changes made during this pass.
|
||||
|
||||
## What was already present in the uploaded project
|
||||
|
||||
The project already contained many of the plan-aligned building blocks:
|
||||
|
||||
- Centralized JWT helpers for actor tokens.
|
||||
- HttpOnly session cookie helpers for admin, employee, and renter sessions.
|
||||
- Company authorization policy helpers.
|
||||
- Admin 2FA and fresh-2FA enforcement middleware.
|
||||
- Public booking access-token helpers.
|
||||
- Webhook idempotency helpers.
|
||||
- Hashed `CompanyApiKey` model and migration.
|
||||
- `ReservationPublicAccess` model and migration.
|
||||
- `WebhookEvent` model and migration.
|
||||
- Upload validation helpers and public/private storage separation.
|
||||
- Request ID and sanitized error response middleware.
|
||||
- Production Docker/Traefik hardening, including Redis authentication and `x-middleware-subrequest` blocking.
|
||||
- Static security scan script and CI security gates.
|
||||
|
||||
That base work was useful, but it had a few security and test-consistency gaps.
|
||||
|
||||
## Additional changes applied in this pass
|
||||
|
||||
### 1. Removed legacy plaintext company API key storage
|
||||
|
||||
The plan requires company API keys to be hash-only. The code had introduced `CompanyApiKey`, but the legacy `Company.apiKey` field still existed in the Prisma schema and middleware still allowed a fallback lookup against that plaintext field when `ALLOW_LEGACY_COMPANY_API_KEYS=true`.
|
||||
|
||||
Changes applied:
|
||||
|
||||
- Removed `Company.apiKey` from `packages/database/prisma/schema.prisma`.
|
||||
- Removed `apiKey` from the local `Company` TypeScript interface in `packages/database/src/index.ts` and `packages/database/src/index.d.ts`.
|
||||
- Removed the legacy plaintext fallback path from `apps/api/src/middleware/requireApiKey.ts`.
|
||||
- Added migration `20260609233000_drop_legacy_company_api_key` to drop the old column and unique index.
|
||||
- Rewrote `requireApiKey` tests around prefix lookup, hash comparison, revocation, and `lastUsedAt` updates.
|
||||
|
||||
Security effect: raw company API keys are no longer accepted through the legacy company column and are no longer represented in the current Prisma schema.
|
||||
|
||||
### 2. Centralized Socket.io token verification
|
||||
|
||||
The main API process still verified Socket.io auth tokens directly with `jwt.verify(token, JWT_SECRET)` and did not enforce issuer, audience, actor type, or allowed algorithm. This contradicted the session-authentication phase of the plan.
|
||||
|
||||
Changes applied:
|
||||
|
||||
- Added `verifyAnyActorToken()` to `apps/api/src/security/tokens.ts`.
|
||||
- Updated `apps/api/src/index.ts` to use centralized actor-token verification for Socket.io authentication.
|
||||
- Removed the direct `jsonwebtoken` import from the main API entrypoint.
|
||||
|
||||
Security effect: Socket.io no longer accepts tokens that bypass the centralized actor-token constraints.
|
||||
|
||||
### 3. Hardened employee password-reset JWT verification
|
||||
|
||||
Employee password-reset tokens were signed and verified directly with the JWT secret and no issuer, audience, or algorithm constraints.
|
||||
|
||||
Changes applied:
|
||||
|
||||
- Added explicit `HS256` signing for employee password-reset tokens.
|
||||
- Added issuer `rentaldrivego-api`.
|
||||
- Added audience `employee_password_reset`.
|
||||
- Added matching verification constraints.
|
||||
|
||||
Security effect: reset tokens now reject wrong issuer, wrong audience, or wrong algorithm instead of relying on a bare shared-secret verification.
|
||||
|
||||
### 4. Repaired test fixtures and middleware tests
|
||||
|
||||
Some tests still expected pre-hardening behavior. That is a bad smell: tests defending old weaknesses are basically tiny lobbyists for future incidents.
|
||||
|
||||
Changes applied:
|
||||
|
||||
- Updated API-key middleware tests to validate hashed-key behavior instead of plaintext `Company.apiKey` lookup.
|
||||
- Updated auth middleware tests to match the centralized token verifier behavior.
|
||||
- Updated integration test helper token generation to use `signActorToken()` so generated test tokens include issuer and audience.
|
||||
|
||||
Security effect: future test runs are less likely to push developers back toward weaker auth behavior.
|
||||
|
||||
## Verification performed in this sandbox
|
||||
|
||||
| Check | Result | Notes |
|
||||
|---|---:|---|
|
||||
| Static security scan | PASS | `npm run security:static` completed successfully. |
|
||||
| Critical production dependency audit | PASS | `npm audit --package-lock-only --omit=dev --audit-level=critical` exited successfully. |
|
||||
| JSON syntax check | PASS | Root and app `package.json` files and lockfile parsed successfully. |
|
||||
| Shell syntax check | PASS | Shell scripts and production entrypoint parsed with `bash -n`. |
|
||||
| YAML parse check | PASS | `docker-compose.production.yml` and `.gitlab-ci.yml` parsed successfully. |
|
||||
| Node script syntax | PASS | `scripts/security-static-check.mjs` passed `node --check`. |
|
||||
| Full dependency install | NOT COMPLETED | `npm ci --ignore-scripts --prefer-offline` could not complete in this sandbox. |
|
||||
| Full type-check/test/build | NOT RUN | Requires dependencies to be installed. Run in CI or a normal development environment. |
|
||||
| Docker compose config/render | NOT RUN | Docker is unavailable in this sandbox. |
|
||||
| Prisma generate/migrate | NOT RUN | Requires dependency installation and a normal Prisma/DB environment. |
|
||||
|
||||
## Dependency audit note
|
||||
|
||||
The critical audit gate passes. The audit still reports moderate findings involving `postcss` through Next.js and `uuid` through Firebase/cron-related dependency chains. The lockfile’s suggested fixes require forced or breaking upgrades, so I did not casually smash the dependency graph with a hammer and call the mess “security.” Those should be handled in a controlled dependency-upgrade ticket with full frontend and notification regression testing.
|
||||
|
||||
## Files changed by this pass
|
||||
|
||||
- `apps/api/src/index.ts`
|
||||
- `apps/api/src/middleware/requireApiKey.ts`
|
||||
- `apps/api/src/middleware/requireApiKey.test.ts`
|
||||
- `apps/api/src/middleware/requireCompanyAuth.test.ts`
|
||||
- `apps/api/src/middleware/requireRenterAuth.test.ts`
|
||||
- `apps/api/src/modules/auth/auth.employee.service.ts`
|
||||
- `apps/api/src/security/tokens.ts`
|
||||
- `apps/api/src/tests/helpers/fixtures.ts`
|
||||
- `packages/database/prisma/schema.prisma`
|
||||
- `packages/database/prisma/migrations/20260609233000_drop_legacy_company_api_key/migration.sql`
|
||||
- `packages/database/src/index.ts`
|
||||
- `packages/database/src/index.d.ts`
|
||||
|
||||
See also:
|
||||
|
||||
- `security_hardening_incremental.diff`
|
||||
- `security_hardening_changed_files.txt`
|
||||
|
||||
## Phase status against the hardening plan
|
||||
|
||||
| Phase | Status | Evidence / caveat |
|
||||
|---|---:|---|
|
||||
| Phase 0: Emergency stabilization | Partial / needs operator action | Static scan passes, placeholders are present, but real production secret rotation cannot be performed inside the archive. |
|
||||
| Phase 1: Sessions and authentication | Substantially applied | HttpOnly session helpers and centralized actor JWT verification exist; Socket.io and reset-token gaps were corrected in this pass. |
|
||||
| Phase 2: Authorization and tenant isolation | Substantially applied | Company policy middleware exists; tenant-safe patterns are present in many modules. Full proof requires test suite and code review across all repository methods. |
|
||||
| Phase 3: Public booking privacy | Applied at source level | Public access token model/helper and safe public booking flow are present. Must be verified with integration tests. |
|
||||
| Phase 4: Admin hardening | Applied at source level | Mandatory 2FA and fresh-2FA middleware are present. Enrollment and recovery-code workflows still need production validation. |
|
||||
| Phase 5: API key hardening | Strengthened in this pass | Legacy plaintext company API key storage/fallback removed; hash-only `CompanyApiKey` path remains. |
|
||||
| Phase 6: Payments and webhooks | Applied at source level | Raw-body webhook handling and idempotency helpers are present. Must be verified against provider test events. |
|
||||
| Phase 7: Upload and storage hardening | Applied at source level | Magic-byte validation and public/private storage split are present. Must be verified with upload abuse tests. |
|
||||
| Phase 8: Rate limiting, errors, browser security | Applied at source level | Request IDs, sanitized errors, rate limit middleware, and security headers are present. Must be verified in deployed environment. |
|
||||
| Phase 9: Deployment hardening | Applied at config level | Redis auth, non-public DB tooling, private networks, and Traefik header blocking are present. Must be verified on the real host. |
|
||||
| Phase 10: Observability, auditability, jobs | Partial | Logging/audit hooks exist, but queue migration and operational observability need dedicated validation. |
|
||||
| CI/CD security gates | Applied at config level | Security scan and critical audit gates exist; full CI must run outside this sandbox. |
|
||||
|
||||
## Required follow-up before launch
|
||||
|
||||
1. Rotate all real production secrets and invalidate old sessions/API keys where appropriate.
|
||||
2. Run `npm ci` in CI or a normal development environment.
|
||||
3. Run `npm run db:generate` and apply the new migration after backup.
|
||||
4. Run full type-check, unit tests, integration tests, e2e tests, and builds.
|
||||
5. Run payment-provider webhook test events using real sandbox provider signatures.
|
||||
6. Verify public/private storage behavior with real uploaded files.
|
||||
7. Verify Redis and PostgreSQL are not externally reachable from the production host.
|
||||
8. Run container image build and Trivy scan.
|
||||
9. Confirm admin 2FA enrollment and fresh-2FA gates before enabling privileged admin actions in production.
|
||||
10. Document any deferrals with owner, risk acceptance, compensating control, deadline, and ticket number.
|
||||
|
||||
## Launch recommendation
|
||||
|
||||
Do not launch publicly yet based only on the patched archive. The source now better matches the plan, and the critical static/audit checks pass, but the hard launch gate still depends on full CI, Prisma migration validation, deployment verification, and production secret rotation.
|
||||
|
||||
The patched archive is suitable for the next CI/staging pass. Treat it as implementation-ready source, not production clearance. Production clearance comes from reproducible evidence, not vibes in a ZIP file.
|
||||
Reference in New Issue
Block a user