CMS - content staging hardening AB#292208

[davidgouge]

AB#292208

[dfe-lance]

Check Performance Data -- Web Application Security Assessment

Service: Check your performance measures data (ASP.NET Core / GOV.UK Frontend)
Assessment window: 18-21 August 2026 (dev stack retested 21 Aug on the current main build)
Prepared by: Automated Security Assessment Tool (OWASP WSTG methodology)
Classification: Confidential -- for the CPD service team

Build under test

Repository	github.com/DFE-Digital/check-performance-data
Branch	main
Commit tested	15f9dfda086a88b2ebf891f55babb364120a16ad (15f9dfda)
Commit date	2026-08-21 16:36:14 +0100
Commit subject	Merge pull request #328 from DFE-Digital/326-worker-di-student-results-client
Tested artifact	Docker image cypd_web:latest, built 2026-08-21 17:42:44 +0100
Runtime	.NET / ASP.NET Core 10.0.9 (Ubuntu 24.04 base)
Both stacks	Dev (:8080) runs this build; production-config (:8443) verified 19-20 Aug

The dev stack (:8080) was retested on 21 Aug 2026 against the current main HEAD after a
fresh rebuild -- the tested image corresponds to commit 15f9dfda (image built after that commit;
worktree clean). All findings below were re-confirmed unchanged on this build. The tested commit
is inferred from the image build timestamp (the image carries no embedded commit SHA -- see A-2).
The production-configuration verification (section 3) was performed 19-20 Aug on commit ebbe8654; its
gating conclusions are architectural and unchanged on main.

---

1. Executive summary

This assessment covered the CPD web service across two locally-run stacks -- a development
configuration and an isolated production-configuration stack raised specifically for testing --
using four complementary techniques: unauthenticated black-box testing, white-box source review,
production-configuration verification, and authenticated role-based testing (editor and admin).

The headline is reassuring. The developer conveniences that make the development stack wide
open (role impersonation, a storage browser, seed/reset tooling) are not present in the production
configuration -- verified live, not assumed. And the application's input-handling defences are
strong: attempts to inject stored or reflected cross-site scripting (XSS) and SQL injection (SQLi)
as both an editor and an administrator were trapped -- dangerous HTML is sanitised on render and
reflected input is output-encoded.

The residual items are mostly low-severity hardening (response headers, cookie flags) plus one
issue worth prioritising: the administrative storage browser can download the application's
cryptographic key material, and that capability is not development-only -- it persists into
production for any sufficiently-privileged administrator.

Overall risk (production configuration)	Low-Medium
Critical / High findings exploitable in production	0 unauthenticated / 1 admin-capability (F-009)
Development-only exposures (gated off in production)	F-008, F-011 (verified 404 in prod)
Injection resistance (XSS / SQLi), editor & admin	Strong -- all attempts trapped

Top priorities

1. F-009 (High) -- exclude the data-protection-keys container (and any secret) from the admin
   storage browser; it should never be downloadable via the UI, even by an admin.
2. F-008 / F-011 (dev-config hygiene) -- the developer back doors are correctly gated off in
   production; the residual risk is that Dev:ToolsEnabled defaults to true and is on in
   deployed non-production (Review/Sandbox) environments. Flip the default to false and ensure
   those environments are network-isolated.
3. F-001 (Medium) -- tighten the Content-Security-Policy (script-src still allows
   'unsafe-inline' / 'unsafe-eval').
4. Low hardening -- add the missing response headers, set Secure on the antiforgery cookie.

---

2. Scope & methodology

Phase	Target	Technique
1 / Unauthenticated	Dev stack :8080	Black-box recon, header/config, injection probing
2 / Source review	DFE-Digital/check-performance-data (read-only)	White-box verification of gating & authorization
3 / Production verification	Prod-config stack https://:8443	Confirm dev doors shut; unauthenticated surface
4 / Authenticated roles	Dev stack :8080 (impersonation)	Editor & admin CRUD injection testing (XSS / SQLi)

Standard: OWASP Web Security Testing Guide (WSTG).
Explicitly excluded: load / stress / denial-of-service (shared host); anything behind a real
DfE Sign-In login on the production stack (no IDP available).
Deliberate, out-of-scope deviations on the local production target (not findings): self-signed
certificate; Zendesk:UseFake=true; Notify:UseFake=true; thin seeded content (5 page nodes).

---

3. Development vs production -- what differs

The development stack is deliberately permissive; the production configuration closes those doors.
This was verified on both stacks.

Capability	Dev stack (:8080)	Production config (:8443)
/dev/impersonate/{admin,editor}	Open -- grants role with no login	404 (gated off)
Forged cypd-dev-impersonation=admin cookie	-> 200, full admin	-> 302 to DfE Sign-In (inert)
/admin/danger-zone, /content-staging, /observability, /Help/Seed	Reachable	404
Admin storage browser (/admin/storage)	Reachable via impersonation	302 challenge (behind real auth)
Session cookie Secure flag	Absent (HTTP)	Present [OK]
HSTS	n/a (HTTP)	Configured (max-age=2592000) [OK]
TLS	n/a	1.2 / 1.3 only; 1.0/1.1 refused [OK]

Verified in source (phase 2): every developer surface is gated on both a Dev:ToolsEnabled
configuration flag and a hard !IsProduction() guard -- "closed twice over". Admin actions use a
fail-closed section-grant authorization grid and return 404 (not 403) to non-granted users to
discourage URL discovery. Destructive actions (e.g. seed reset) are POST + antiforgery behind a
warning interstitial, not GET.

Correction from black-box testing: an early finding that flagged reset-seed-data as a
dangerous GET was retracted after source review -- the GET only renders a confirmation page; the
destructive action is a protected POST. Reported here for transparency.

---

4. Consolidated findings

Severity reflects production impact. "Dev-only" items are real on the dev stack but gated off in
production.

ID	Finding	Severity	Prod status
F-009	Admin storage browser can download/delete the Data Protection keyring	High	Open (any storage-admin)
F-008	Role impersonation via client-set cookie where Dev:ToolsEnabled is on	High	Dev/Review-only (prod: inert)
F-011	Developer/diagnostic surface (impersonation, seed, storage)	Medium	Dev/Review-only (prod: 404)
F-001	CSP allows 'unsafe-inline' and 'unsafe-eval'	Medium	Open (both stacks)
F-002	Session cookie missing Secure	Medium	Fixed in prod
P-003	Antiforgery cookie missing Secure	Low	Open (prod)
F-004	X-Content-Type-Options: nosniff missing	Low	Open (both)
F-005	Referrer-Policy missing	Low	Open (both)
P-001	HTTP methods unrestricted (TRACE enabled; no XST)	Low	Open (prod)
A-1	Rich content stored raw, sanitised on output only	Low	Open (defence-in-depth)
F-006	Permissions-Policy missing	Info	Open (both)
F-007	Server: Kestrel banner	Info	Open (both)
A-2	No build provenance (commit SHA) embedded in the image	Info	Open (both)

Retracted after source review: F-010 (reset-seed-data "dangerous GET").
Not a finding: HSTS "absent" was a localhost testing artifact (ASP.NET Core excludes localhost);
HSTS is correctly emitted for real hostnames.

Full per-finding detail (reproduction, impact, ASP.NET Core remediation) is in the Appendix.

---

5. Authenticated role-based testing (editor & admin)

Using the development impersonation mechanism, both roles were tested against the CRUD surfaces with
the specific goal you set: can a logged-in editor or administrator inject cross-site scripting,
dangerous JavaScript, or SQL -- and is it trapped?

Result: injection is trapped for both roles [OK]

Test	Vector	Result
Stored XSS via CMS content blocks (editor & admin)	<script>, <img onerror>, <svg>, <iframe>	Sanitised on render -- script/handlers/js-URIs stripped; safe tags kept. Headless-browser confirmed no execution.
Sanitiser bypass attempts	javascript: URIs (incl. jAvAsCrIpT:), formaction, ontoggle, onmouseover, mutation vectors	All neutralised -- every event handler and script/JS-URI removed.
Reflected XSS	Admin message filter, search params	Output-encoded (</>/" -> entities) -- no breakout, no execution.
SQL injection	Message filter, observability search, submissions, settings	None -- no SQL errors, no time-based delay (pg_sleep test flat).
Role scoping (editor)	/admin/settings, /system/roles, /storage, /Messages	Correctly denied (404) -- editor limited to content & pages.

The content pipeline stores the raw HTML an author submits but sanitises it on output with a
robust allow-list (consistent with the HtmlSanitizer library). This is effective; see A-1 for a
defence-in-depth recommendation to also sanitise on input.

The one administrator lever to tighten

An administrator (real or impersonated) with the storage-admin grant can browse the blob storage
account and download the ASP.NET Core Data Protection keyring (keys.xml, containing the master
key), and delete blobs. Confirmed: GET /admin/storage/app/data-protection-keys/download?blob=keys.xml
-> 200 application/xml. With those keys an attacker can forge/decrypt authentication, session and
antiforgery tokens. This is not gated to development -- it is a genuine production concern and is
tracked as F-009. Administrators are trusted, but a secret keyring should never be reachable
through the application UI. (Key material was confirmed retrievable; it was not exfiltrated or
decoded.)

---

6. What is already done well

Worth stating plainly -- the development team has built with security in mind:

• Developer tooling is gated twice (Dev:ToolsEnabled and !IsProduction()); production
  serves none of it.
• Robust HTML sanitisation of authored content -- stored-XSS attempts by editors and admins are
  neutralised on render.
• Consistent output encoding on reflected inputs; no SQL injection found anywhere tested.
• Fail-closed authorization with a configurable section-grant grid; non-granted users get 404,
  not 403 (discourages discovery). Editor role is correctly scoped.
• Destructive actions are POST + antiforgery behind confirmation screens.
• Production transport is solid -- TLS 1.2/1.3 only, HSTS configured, session cookie Secure,
  HTTP->HTTPS redirect.
• No source/config exposure (.git, .env, appsettings, swagger all 404); generic error
  pages (no stack traces); minimal health endpoint.

---

7. Remediation priorities

1. [High] F-009 -- Deny-list secret containers (data-protection-keys) from the storage browser;
   remove raw download/delete of arbitrary blobs; store DP keys in Key Vault. Rotate keys if the
   keyring may have been exposed.
2. [Med] F-008 / F-011 -- Default DEV_TOOLS_ENABLED to false; add a CI/DAST check asserting
   /dev/impersonate/admin -> 404 per deployed environment; network-isolate non-production apps.
3. [Med] F-001 -- Move CSP off 'unsafe-inline'/'unsafe-eval' (nonces).
4. [Low] P-003 / F-004 / F-005 / P-001 -- Set Secure on the antiforgery cookie; add
   X-Content-Type-Options, Referrer-Policy, Permissions-Policy; restrict HTTP methods / disable
   TRACE; suppress the Server banner.
5. [Low] A-1 -- Sanitise rich content on input as well as output (defence-in-depth).
6. [Info] A-2 -- Embed the build's commit SHA in the image (label
   org.opencontainers.image.revision and/or a /version value) so a deployed artifact can be tied
   to an exact source revision -- it had to be inferred from the build timestamp here.

---

8. Coverage & gaps

• Authenticated production testing was not possible (no DfE Sign-In / IDP on the local prod
  stack). Authenticated behaviour was exercised on the development stack via impersonation; the
  production authorization boundary itself was verified only to the point of the sign-in challenge.
• F-009 could not be exercised on production (it sits behind the real login there) -- assessed via
  the development stack and source; the design fix applies regardless.
• Load / DoS excluded by request (shared host).
• Thin seeded content on the production stack limited content-route coverage there.
• Testing was point-in-time against the build current on 18-20 Aug 2026.

---

Appendix -- finding details

Detailed, reproducible write-ups (with ASP.NET Core remediation) exist as individual records:

• Development-stack engagement (localhost-8080-2026-08): F-001 - F-009, F-011.
• Production-configuration engagement (cypd-prod-2026-08): P-001, P-002, P-003.

Full technical detail for each finding -- request/response evidence, CVSS vectors, CWE/WSTG
references, and code-level fixes -- accompanies this report per engagement.