Static security scanner reports stale/false-positive CORS finding after source text changed

[ajianaz]

Bug Summary

cora review produces a SARIF finding "CORS wildcard allows all origins" on a line that does not contain the words "wildcard" or "all origins". The finding persists across multiple commits even after the flagged text was reworded — suggesting the static security scanner is either caching results or matching on a stale diff.

Reproduction

Repository

• Repo: codecoradev/titen
• Branch: docs/deploy-and-usage-guide (now merged to develop)
• Trigger: cora review --format sarif --severity major via cora-review-action

Step-by-step

1. Commit 1 (e6446cd) — Original text at docs/architecture.md:89:

   CORS — configurable via TITEN_CORS_ORIGINS. Only listed origins are allowed; malformed entries are silently skipped (no wildcard, no panic).

   This line contains the words "CORS" + "wildcard" in the same sentence (in a negation context: "no wildcard"). The scanner correctly flags it as suspicious.

2. Commit 2 (3ba2228) — Reworded to remove "wildcard":

   CORS — configurable via TITEN_CORS_ORIGINS. Only explicitly listed origins are permitted; malformed entries are silently skipped. No catch-all origin pattern is permitted. Default: same-origin only.

   Scanner still flags the line — even though "wildcard" and "all origins" are no longer present. SARIF output unchanged (same message, same ruleId).

3. Commit 3 (a46ad77) — Reworded again, removed "all origins" and "catch-all":

   Set TITEN_CORS_ORIGINS — Restrict cross-origin policy to your exact domain (e.g., https://titen.yourdomain.com). Do not leave this unset in production.

   Scanner STILL reports the same finding at docs/deployment.md:628:

   {
     "annotation_level": "failure",
     "message": "Static security scanner detected: CORS wildcard allows all origins in docs/deployment.md:628",
     "path": "docs/deployment.md",
     "start_line": 628,
     "title": "CORS wildcard allows all origins"
   }

Verified: line 628 at commit a46ad77

- [ ] **Set `TITEN_CORS_ORIGINS`** — Restrict cross-origin policy to your exact domain
      (e.g., `https://titen.yourdomain.com`). Do not leave this unset in production.

No "wildcard", no "all origins", no "catch-all" — yet the finding persists.

Expected Behavior

1. Static security scanner should re-evaluate file contents on each commit, not reuse cached results.
2. Scanner should not flag negation contexts — "no wildcard" and "no catch-all" are security-positive statements.
3. When source text is changed to remove the flagged pattern, the finding should disappear on the next cora review run.

Actual Behavior

• cora review exits 0 (success) but produces SARIF with 1 level: error finding
• The finding has the same message and ruleId across 3 different commits with 3 different texts at the flagged line
• GitHub Code Scanning creates a check-run (CodeCora) with conclusion: failure because of the level: error finding
• This blocks PRs from being merged without --admin override

Impact

• Severity: Medium — blocks CI green status on repos using cora-review-action
• Workaround: Merge with gh pr merge --admin (bypass), or disable upload-sarif
• Affected: Any repo using cora-review-action with upload-sarif: true that mentions "CORS" in documentation

Environment

Component	Version
cora-code	v0.12.0 (latest release at time of writing)
cora-review-action	v1.0.2
Runner OS	ubuntu-latest (GitHub Actions)
SARIF output	1,605 bytes, 1 result, exit code 0

Evidence

CI Run Logs (PR #39, commit a46ad77)

Attempt 1: exit=0, sarif_bytes=1605
Cora review complete (1605 bytes, exit=0, attempts=1)
SARIF contains 1 finding(s) — will upload.
Successfully uploaded results

Check-run annotation

{
  "annotation_level": "failure",
  "blob_href": "https://github.com/codecoradev/titen/blob/a46ad77.../docs/deployment.md",
  "end_line": 628,
  "message": "Static security scanner detected: CORS wildcard allows all origins in docs/deployment.md:628",
  "path": "docs/deployment.md",
  "start_line": 628,
  "title": "CORS wildcard allows all origins"
}

GitHub Code Scanning API (post-merge)

GET /repos/codecoradev/titen/code-scanning/alerts → []

Zero open alerts — confirming the finding is a false positive that GitHub already dismissed but the check-run remains.

Suspected Root Causes

1. Stale diff cache — cora review computes diff against base branch (origin/develop). If the diff is cached by content hash and the file was modified between commits, the scanner may be evaluating the old version of the file.
2. Overly broad pattern match — The CORS security rule may match on keyword CORS alone, or on CORS + any of {wildcard, all, *} without checking context (negation, documentation vs code).
3. SARIF ruleId not deduplicated — Each run produces a new SARIF result with the same ruleId, but GitHub Code Scanning fingerprinting may be associating it with the first occurrence.

Suggested Fixes

1. Short-term: Narrow the CORS security rule to match actual code patterns (e.g., Access-Control-Allow-Origin: * in source files), not documentation text.
2. Short-term: Add file-type filtering — .md files should not trigger source-code security rules.
3. Long-term: Implement context-aware scanning that understands negation ("no wildcard", "do not use catch-all") and skips those as security-positive statements.
4. Investigate: Verify diff computation in cora review is always fresh per-commit (no stale cache).

Related PRs

• codecoradev/titen#38 — First occurrence (architecture.md CORS description)
• codecoradev/titen#39 — Second occurrence (deployment.md security checklist)

Both PRs required --admin merge bypass due to this false positive.