CSP permits unsafe string-to-code evaluation
ShipReady found the unsafe-eval source expression in the effective script policy.
Why it matters
Allowing string-to-code evaluation can broaden the script behaviors that a Content Security Policy permits. Whether it creates a practical issue depends on application code and other controls; the policy token alone does not demonstrate arbitrary code execution.
How ShipReady detects it
What it inspects
ShipReady parses the enforcing Content-Security-Policy header and inspects effective script sources: script-src when present, otherwise the default-src fallback.
What triggers a finding
The rule triggers when the effective script sources contain the unsafe-eval token, with token matching performed case-insensitively.
What the evidence shows
The report identifies whether the observed source value came from script-src or the default-src fallback and records the source value parsed for the finding.
Limits of this check
ShipReady does not execute JavaScript, determine whether the application calls evaluation APIs, inspect script-src-elem or script-src-attr, or analyze a separate Report-Only policy. A matching policy token does not prove arbitrary code execution or a successful attack.
How to fix it
Remove the need for string-to-code evaluation
Replace dynamic evaluation patterns with structured data handling, explicit dispatch, or other code paths that do not require unsafe-eval.
Tighten and test the script policy
Remove unsafe-eval from the effective script sources after testing the application paths that depend on third-party libraries or dynamic code behavior.
How to verify the change
Verify the deployed script policy
Inspect the enforcing Content-Security-Policy header and determine the effective script sources, including default-src fallback when script-src is absent.
Expected: The effective script policy no longer contains unsafe-eval unless its continued use is a deliberate, reviewed requirement.