Content-Security-Policy header is absent
ShipReady did not find a non-empty enforcing Content-Security-Policy header on the successfully fetched content response.
Why it matters
A deliberate Content Security Policy can provide an additional browser-side boundary for the resources a page is allowed to load or execute. Its absence is a configuration gap worth reviewing, even though it does not by itself establish that an application is exploitable.
How ShipReady detects it
What it inspects
ShipReady reads response headers from the successfully fetched page and normalizes header names before looking for the enforcing Content-Security-Policy header.
What triggers a finding
The rule triggers when that enforcing header is missing or has an empty value.
What the evidence shows
The finding establishes that ShipReady did not receive a non-empty enforcing Content-Security-Policy header for that fetched content response.
Limits of this check
ShipReady skips failed or non-content responses, checks the fetched response rather than every route, and does not use a Content-Security-Policy-Report-Only header for this rule. The finding does not evaluate every client-side defense or prove an injection vulnerability can be exploited.
How to fix it
Define an enforcing policy for the application
Decide which script, style, image, connection, frame, and other resource origins the application needs, then send an enforcing Content-Security-Policy header that reflects those requirements.
Roll out and refine the policy safely
Test representative application flows and use reporting or staged deployment where appropriate before tightening permitted sources.
How to verify the change
Inspect the deployed response header
Request the affected page and inspect its response headers after deployment.
Expected: The content response includes a non-empty enforcing Content-Security-Policy header that matches the intended policy.