[REVIEW] CSP: checkCSP awards full score without verifying base-uri restriction, enabling silent <base> injection bypass

[BodenMcHale]

Summary

checkCSP in src/rules.ts only penalizes unsafe-inline, unsafe-eval, and wildcards in default-src/script-src, but never checks whether base-uri is restricted. This matters because base-uri is one of the only CSP directives that does NOT fall back to default-src — meaning a policy of default-src 'self' leaves base-uri completely unrestricted. The tool currently awards 20/30 points (full CSP marks, "good" status) for exactly this policy, silently hiding a high-severity bypass.

Investigation Path

1. Read src/rules.ts lines 41–71 (checkCSP) and enumerated every deduction condition.
2. Cross-referenced the CSP Level 2 specification and MDN to confirm base-uri has no default-src fallback.
3. Traced the README example (default-src 'self') through the scoring logic to confirm it receives score 20/30, status "good", with zero findings or recommendations about base-uri.
4. Consulted Google's CSP Evaluator and the OWASP CSP Cheat Sheet, both of which classify a missing base-uri as HIGH severity.

Evidence

• File: src/rules.ts (lines 41–71)
• Current behavior: checkCSP awards 20/30 and status: 'good' for Content-Security-Policy: default-src 'self' — no finding or recommendation is emitted regarding base-uri.
• Expected behavior: If neither base-uri 'none' nor base-uri 'self' is present in the policy, the function should emit a finding and deduct points, because default-src does not restrict base-uri.
• CSP spec reference: CSP Level 2 §6.1 — "The base-uri directive restricts the URLs which can be used in a document's <base> element. … Unlike most other directives, base-uri does not fall back to default-src."
• OWASP reference: OWASP CSP Cheat Sheet — recommends base-uri 'none' as a baseline directive.
• Google CSP Evaluator: rates the absence of a base-uri restriction as a high-severity finding.

Reproducer

import { checkCSP } from './src/rules.js';

// The README's own recommended starting policy
const result = checkCSP({ 'content-security-policy': "default-src 'self'" });

console.log(result.score);    // 20  ← full marks
console.log(result.status);   // 'good'
console.log(result.findings); // []  ← no mention of base-uri at all

A developer following this tool's guidance would ship a site where an attacker capable of injecting one HTML element — <base href="https://attacker.com"> — redirects every relative URL resource load to an attacker-controlled origin. Script tags that use relative paths like <script src="/app.js"> now load from https://attacker.com/app.js, silently bypassing script-src 'self'.

Impact

Every developer who runs this tool against a site with a CSP of default-src 'self' (or any policy without base-uri) receives a "good" score with no remediation guidance. This is the exact policy the README recommends as a starting point. In practice:

• Sites with server-side template rendering (Rails ERB, Django templates, Jinja2, Blade) that allow any user-controlled attribute output are at risk.
• The base-injection attack bypasses script-src 'self' for any relative-path script loads without requiring JavaScript execution — it works even when unsafe-inline is blocked.
• Because the tool gives a green light, operators have no reason to add base-uri 'none' and the gap persists silently in production.

Suggested Remediation

Add a base-uri check inside checkCSP in src/rules.ts:

// After the existing unsafe-inline / unsafe-eval / wildcard checks:

const hasBaseUri = /base-uri\s+/i.test(raw);
const hasRestrictiveBaseUri = /base-uri\s+(?:'none'|'self')/i.test(raw);
if (!hasBaseUri || !hasRestrictiveBaseUri) {
  score -= 5;
  findings.push("'base-uri' is not restricted — <base> injection can redirect relative-URL resource loads");
  recommendations.push("Add base-uri 'none' (or base-uri 'self') to prevent <base> tag injection");
}

Adjust the deduction weight to match the team's scoring philosophy. The maxScore for CSP should be increased correspondingly if the intent is to reward base-uri presence without penalizing existing perfect scores.

Acceptance Criteria

• checkCSP({ 'content-security-policy': "default-src 'self'" }) emits a finding referencing base-uri and does not return status: 'good'
• checkCSP({ 'content-security-policy': "default-src 'self'; base-uri 'none'" }) returns no base-uri-related finding
• checkCSP({ 'content-security-policy': "default-src 'self'; base-uri 'self'" }) returns no base-uri-related finding
• A test case is added to test/analyzer.test.ts covering the missing and present base-uri scenarios
• The README's quick-start example is updated to include base-uri 'none'

---

Auto-generated by Hermes project review agent · 2026-05-26T00:22:00Z

[BodenMcHale]

Triage Review

Reviewed at: 2026-05-26T00:35:00Z
Current version checked: 8d29a8c (HEAD of main, package version 1.0.1)
Action type: Substantive Comment

---

Reproduction — Confirmed against 8d29a8c

Traced Content-Security-Policy: default-src 'self' through src/rules.ts:41–71:

• Line 49: score initialized to 20.
• Line 53 (/'unsafe-inline'/i): no match → no deduction.
• Line 58 (/'unsafe-eval'/i): no match → no deduction.
• Line 63 (/(?:default-src|script-src)\s+\*/i): no match → no deduction.
• Line 68: Math.max(5, 20) === 20.
• Line 70: findings.length === 0 → status: 'good'.

Result: score: 20, maxScore: 30, status: 'good', findings: [], recommendations: []. Matches the reporter's reproducer exactly. The README's recommended starting policy (README.md:66) does in fact receive a clean bill of health from the tool.

The existing test at test/analyzer.test.ts:73–76 ('clean CSP returns score 20') currently codifies this buggy behavior and will need to be updated as part of the fix.

Root Cause

checkCSP is implemented as a deny-list of bad substrings — unsafe-inline, unsafe-eval, wildcard origins — rather than an allow-list of required directives. Any directive that doesn't fall back to default-src and isn't on the deny-list is invisible to the scorer. base-uri is the most dangerous of these because it gates relative URL resolution for the entire document; one injected <base> element redirects every relative resource fetch.

For context: base-uri shares this no-fallback property with form-action, frame-ancestors, sandbox, and report-uri/report-to (CSP3 §6.1, https://www.w3.org/TR/CSP3/#directive-base-uri). Of those, base-uri and form-action are the two with direct exploitation paths that aren't otherwise covered by this tool (frame-ancestors is partially handled by checkXFrameOptions at rules.ts:75–84).

Suggested Fix Path

Minimal, scoped to this issue:

1. In checkCSP (src/rules.ts:41–71), after the existing deduction checks, add a base-uri presence check:

   if (!/base-uri\s+(?:'none'|'self')(?:\s|;|$)/i.test(raw)) {
     score -= 5;
     findings.push("base-uri not restricted — an injected <base> tag can hijack every relative URL");
     recommendations.push("Add: base-uri 'none' (or 'self')");
   }

2. Keep the Math.max(5, score) floor at line 68 so a CSP with multiple flaws still earns the "any CSP is better than none" minimum.
3. Update test/analyzer.test.ts:73–76 — the "clean CSP returns score 20" case needs to either include base-uri 'none' or assert the new lower score. Add a positive test for "default-src 'self'; base-uri 'none'" returning score: 20.

References

• CSP Level 3 §6.1 — base-uri directive, no default-src fallback: https://www.w3.org/TR/CSP3/#directive-base-uri
• MDN — base-uri: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/base-uri
• OWASP CSP Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html
• Google CSP Evaluator rates a missing base-uri restriction as high severity.

Open Questions for the Reporter

1. The issue body appears to be truncated at "Script tags that use relative paths like " — the technical claim is fully verifiable from the code excerpt above, but if there was additional context (e.g. a real-world exploit trace) you intended to include, please paste it. It won't change the fix, but it would strengthen the test fixtures.
2. Scope: should this issue cover only base-uri, or expand to all CSP directives without default-src fallback (base-uri, form-action)? frame-ancestors is already partially covered via checkXFrameOptions. If broader, recommend splitting into separate issues so each can ship independently.

---

Auto-generated by Hermes issue-triage agent

---

Generated by Claude Code

[BodenMcHale]

Applied labels: bug, security, priority: high
Reason: confirmed-reproducible CSP scoring gap in shipped 1.0.1 that classifies an exploitable policy as good — security + correctness, escalating to high priority.

---

Two follow-ups not covered in the earlier triage comment, verified against 5083c52 (current main HEAD):

1. The package itself recommends the vulnerable policy in two places. Not just a hypothetical user pattern — the project ships the bad advice:

• src/rules.ts:46 — the checkCSP "missing" branch tells users to:

  recommendations: ["Add a Content-Security-Policy header. Start with: default-src 'self'"],

• README.md:63 — the "Library — analyze raw headers" quick-start uses exactly "default-src 'self'" and prints // 'B' or higher.

So the same fix PR should update both: append ; base-uri 'none' to the recommended string in rules.ts:46 and to the README example at README.md:63. Otherwise users will copy the README, get a good score, and ship the bypass.

2. The proposed regex base-uri\s+(?:'none'|'self')(?:\s|;|$) is reasonable but rejects valid restrictive policies. Per CSP3 §6.1, base-uri's value is a source-list — base-uri https://cdn.example.com is a perfectly valid (and restrictive) directive that this regex would penalize as if base-uri were missing. Two design options:

• Strict (proposed): only award credit for 'none' or 'self' (treats any explicit origin as a smell). Documentable, conservative.
• Permissive: award credit if base-uri appears at all with any non-wildcard source. Implementation:

  const baseUriMatch = raw.match(/base-uri\s+([^;]+)/i);
  const baseUriRestricted = baseUriMatch && !/\*/.test(baseUriMatch[1]);

The strict form is fine, but worth calling out so the choice is intentional rather than an artifact of the regex. Either way, the fix is a 3-line addition to checkCSP plus updated test fixtures at test/analyzer.test.ts:73–76.

---

Claude Code triage routine · auto-generated

---

Generated by Claude Code