feat(web): add security headers to corporate platform Next.js config

[odarome132]

Closes #547

Summary

Implements the security-header hardening requested in #547 for the corporate platform web app. next.config.ts now applies a baseline security header set to every route via a headers() rule with source: '/(.*)' — previously the app had only Cache-Control caching rules and zero browser-side hardening.

Note on the issue text: it states next.config.ts "sets no headers() function at all." That part is outdated — a caching-only headers() already existed. The real gap (no security headers) is exactly what this PR fixes; the existing caching rules are untouched.

What changed

• corporate-platform/corporate-platform-web/next.config.ts — new buildSecurityHeaders() helper, applied to all routes before the existing cache rules (no header-key overlap).
• corporate-platform/corporate-platform-web/src/next-config.test.ts — 11 vitest cases following the repo's pattern (colocated src/**/*.test.ts, vitest globals).
• corporate-platform/corporate-platform-web/SECURITY_HEADERS.md — single source of truth for the header set, dev/prod differences, CSP design, and coordination with a future vercel.json.

Key design decisions

• Environment-aware CSP. Dev CSP keeps 'unsafe-eval' and ws:/wss: so Next.js hot reload keeps working; production drops both. Strict-Transport-Security is production-only (max-age=63072000; includeSubDomains; preload) so plain http://localhost is never locked out in dev.
• CSP connect-src is built from NEXT_PUBLIC_API_BASE_URL (default http://localhost:4000), so API calls are not blocked once the policy is enforced.
• img-src mirrors images.remotePatterns (unsplash, pinata, jsdelivr, stellar) — a test asserts they stay in sync, so there's no regression for images.unsplash.com.
• script-src 'self' 'unsafe-inline' is the documented minimum: Next.js injects inline bootstrap scripts and no nonce/hash strategy exists yet. Tightening is flagged as follow-up.
• frame-ancestors 'none' + X-Frame-Options: DENY block clickjacking of authenticated corporate users.

Acceptance-criteria checklist

• next.config.ts exports an async headers() applied to all routes — source: '/(.*)'
• Responses include Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy — test-verified
• Strict-Transport-Security present in production — max-age=63072000; includeSubDomains; preload, test-verified
• CSP connect-src allows the configured API base URL — test-verified (default + custom NEXT_PUBLIC_API_BASE_URL)
• Local dev hot-reload unaffected — dev CSP includes 'unsafe-eval' + ws:/wss:, test-verified
• A test verifies header presence and values — src/next-config.test.ts (11 tests)
• No inline script/style required by the app is blocked — script-src/style-src keep 'unsafe-inline' (documented minimum)
• Header configuration documented — SECURITY_HEADERS.md
• X-Frame-Options: DENY prevents iframe embedding — header asserted by test; browser-enforced
• No regression in images.remotePatterns behavior — config untouched; img-src kept in sync, test-verified

Test output + coverage

npm test      → Test Files 30 passed (30) · Tests 323 passed (323)
npm run lint  → tsc --noEmit, exit 0

Coverage for the changed file (npx vitest run src/next-config.test.ts --coverage --coverage.provider=v8 --coverage.include=next.config.ts):

File            | % Stmts | % Branch | % Funcs | % Lines
next.config.ts  |   90.54 |      100 |      50 |   90.54

The uncovered lines are the pre-existing redirects()/rewrites() functions, outside this change's scope — every line of the new security-header code is covered. No coverage threshold is configured in the repo; @vitest/coverage-v8 was installed locally for the report only and is not committed (no lockfile churn).

Honest follow-ups

• Replace script-src 'unsafe-inline' with a nonce/hash strategy (Next.js middleware or custom server) for a strict CSP.
• Consider a Content-Security-Policy-Report-Only rollout with a reporting endpoint before tightening further.
• The issue's "no headers() at all" claim is outdated (caching headers existed); the security headers were indeed missing.

Security note

These headers block clickjacking (X-Frame-Options: DENY + frame-ancestors 'none'), MIME-sniffing (nosniff), referrer leakage (strict-origin-when-cross-origin), unused permission abuse (Permissions-Policy), and protocol downgrade (HSTS, production). The CSP is intentionally permissive on script-src until a nonce strategy lands; nothing in the current app is blocked by it.

[drips-wave]

@odarome132 Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits