Security Update: Explicit CORS Policy (SEC-13)
Security Update: Explicit CORS Policy (SEC-13)
Version: 1.0.421
Control: SEC-13
Affected file: next.config.ts
Overview
This release hardens the platform's Cross-Origin Resource Sharing (CORS) posture by introducing an explicit, documented CORS policy in next.config.ts.
Prior to this change, no Access-Control-Allow-Origin header was explicitly set anywhere in the application — neither in next.config.ts nor in individual API route handlers. While the Next.js App Router applies same-origin policy by default (which is safe in isolation), the absence of an explicit configuration meant:
- There was no auditable record of the intended CORS policy.
- No enforced domain allowlist existed in the codebase.
- A future contributor could inadvertently introduce a wildcard (
Access-Control-Allow-Origin: *) without a clear policy to contradict it.
What Changed
next.config.ts — Explicit CORS headers
The headers() configuration in next.config.ts now explicitly defines CORS behaviour for all routes:
- Public-facing routes that are intended to be callable cross-origin set
Access-Control-Allow-Originto a specific production domain allowlist (e.g. the verified app URL). - Internal-only API routes deliberately omit
Access-Control-Allow-Origin, which is an explicit enforcement of the cross-origin block — not a passive omission.
Policy rationale
| Scenario | Previous behaviour | New behaviour |
|---|---|---|
No Access-Control-Allow-Origin header | Implicit — relied on browser default | Explicit — intentional omission documented in config |
| Internal API routes | No header (passive) | No header (active policy decision) |
| Future cross-origin consumers | Risk of wildcard being added | Must update the domain allowlist explicitly |
Why This Matters
This platform handles sensitive UK tax data and connects directly to HMRC via OAuth. A permissive or misconfigured CORS policy could expose API endpoints to cross-origin requests from untrusted origins, potentially enabling:
- Cross-site request forgery (CSRF) against authenticated sessions.
- Unintended data exposure to third-party scripts.
- Credential exfiltration in the event of a subdomain compromise.
By making the CORS policy explicit and code-reviewable, any future changes to allowed origins require a deliberate, visible modification to next.config.ts rather than an ad-hoc header addition in an API handler.
Action Required
This is an infrastructure-level change with no impact on end users or existing integrations. No action is required from users or API consumers.
If you operate a legitimate cross-origin integration with this platform, contact your account administrator to have your origin added to the verified domain allowlist.