In one paragraph
The CSP keyword unsafe-eval permits JavaScript string evaluation that an applicable script policy would otherwise block. It can enable eval(), the Function constructor, and string-based timers throughout the document. Remove it after identifying dependent code and testing a stricter policy. Its presence weakens one CSP protection; it does not by itself prove that an attacker can inject or execute code.
Why it matters
A policy that restricts script loading can still permit trusted scripts to turn strings into executable JavaScript. unsafe-eval enables that behaviour. If application code passes attacker-controlled text into an evaluation function, removing the permission can block that execution path.
The risk depends on the code, not just the keyword. A page does not become exploitable merely because unsafe-eval exists, and removing it does not fix every injection vulnerability. It is one layer of defence alongside output handling, sanitisation, dependency maintenance, and suitable script-source restrictions.
Nonces and hashes do not cancel unsafe-eval. Unlike unsafe-inline in a nonce-aware policy, this keyword continues to authorise string evaluation when it appears beside nonce or hash expressions. It is also document-wide rather than scoped to a particular permitted vendor host.
How WebAuditOS evaluates this finding
The supplied check looks for unsafe-eval in script-src, falling back to default-src if script-src is absent. The keyword there fails; its absence passes. Pages without an enforcing CSP are not graded by this check and belong under the missing-policy finding instead.
With multiple enforced policies, the documented check fails only when every policy permits evaluation. A browser operation has to satisfy every applicable policy. Report-only policies do not add enforcement, and the check is not a full analysis of every JavaScript execution mechanism.
How to fix it
- Inspect the final document response. Find the enforcing CSP header and determine whether script-src or its default-src fallback contains unsafe-eval. Check application, CDN, and proxy configuration for additional policies.
- Reproduce the affected page in staging without the keyword. Exercise its interactive features with the browser Console open. The violation can identify the script and call site that attempted evaluation.
- Check the production build configuration. Eval-based development source maps, development bundles, or runtime template compilers are possible causes. Do not assume every framework requirement indicates an accidentally deployed development build: some production applications deliberately use runtime compilation or expression evaluation.
- Review the dependent library's supported alternatives. Options may include precompiled templates, a runtime-only build, a no-eval distribution, or a maintained replacement. Test the version you actually deploy. Do not replace eval with new Function and expect the policy restriction to disappear.
- Test a stricter candidate in report-only mode while retaining the existing enforced policy. Copy your complete intended policy and remove unsafe-eval; do not replace it with a simplified example that blocks unrelated dependencies. Configure a working reporting endpoint and review actual journeys, including account settings, dashboards, and payment screens.
- Once legitimate dependencies work, remove the keyword from the enforcing policy. If it was inherited from default-src, check that fallback too. Verify every relevant response and repeat the browser tests after deployment.
- Rescan in WebAuditOS and monitor production errors and CSP reports. A scan result cannot replace testing a rarely used feature that invokes an evaluator only after interaction.
If an unavoidable third-party component requires dynamic evaluation, document the residual risk and consider isolation in a separate origin or a suitably sandboxed frame. Do not assume adding its hostname makes the keyword apply only to that vendor.
What the fix can break
A blocked evaluation can leave a chart blank, a template unrendered, or an expression-based filter unusable. The server may still return successful responses, so server uptime monitoring alone will miss the failure.
Third-party tags and older libraries may evaluate strings only for certain configurations or campaigns. A quick homepage check can therefore miss the feature that breaks later.
Removing the keyword without resolving the dependency can cause a real outage. Keeping it indefinitely because one component requires it is also a tradeoff, not proof that the rest of the policy is ineffective. Preserve the remaining restrictions while planning the dependency change.
Questions
Can unsafe-eval be allowed for only one script?
Not within a single document's ordinary CSP source list. The keyword enables evaluation document-wide. A hostname next to it does not limit that permission to code from that host.
Does a nonce make unsafe-eval safe?
No. A nonce authorises matching script elements; unsafe-eval permits a separate execution mechanism. It still works in a directive that contains a nonce or hash.
Why does WebAuditOS not grade a page with no CSP here?
The supplied rule evaluates an existing enforced policy. A missing policy is a separate issue, not a pass for evaluation restrictions.
Which related pages help complete the fix?
Review the missing CSP header, missing default-src, and the security headers guide.