TC-009 - I2 String-to-code evaluation
eval with hardcoded string
Context profile
No restrictive Content Security Policy is present. A session-like cookie is readable by JavaScript.
Content Security Policy
No Content-Security-Policy header is sent.
Cookies
| Cookie | Type | HttpOnly | Secure | SameSite |
|---|---|---|---|---|
tc_session | session-like | no | no | Lax |
Cookie values are placeholders and are never collected. Of these attributes only HttpOnly decides whether JavaScript can read the cookie.
Test case
The script passes a hardcoded string ('6 * 7') to eval. There is no query parameter and no other input flow, so no
attacker-controlled data reaches the sink. This is the hardcoded-string counterpart of TC-005.
Script output
What to observe
- Under C0 the output shows
eval returned: 42- the same result as TC-005's arithmetic example, but here the evaluated string is a fixed literal, not URL input. - Under C1 the CSP without
unsafe-evalblocks eval, so it throwsEvalError(visible in the console) and the output stays empty. - There is no
locationread: the string is visible in the served script as a constant.
The finding on eval is technically correct, but lower-risk because no attacker-controlled
input is visible - the I2 equivalent of TC-004 for I1. The context profiles change the expected
priority without changing the static finding.
Expected outcome
- Purpose
- Check how a technically correct eval finding is handled when no attacker-controlled input is visible.
- Expected finding
- Finding on eval.
- Expected interpretation
- Technically relevant indicator, but lower-risk or ambiguous because no input flow is visible.
- Expected priority
- Low to medium (C0)
- Notes
- Useful case for checking that interpretation does not overclaim.
Expected priority is shown for the active context profile. Other profiles for this case: C0, C1.