fix: external api calls using fetch() lack integrity... in files.js#722
Conversation
Automated security fix generated by OrbisAI Security
📝 WalkthroughWalkthrough
ChangesProject JSON Fetching
Estimated code review effort: 1 (Trivial) | ~5 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment Warning |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@main/files.js`:
- Around line 404-407: Update loadWorkspace so the ?project= fetch path uses
fetchProjectJson with validatedUrl.href instead of calling fetch directly,
ensuring every project fetch applies the HTTPS-only external URL validation.
Preserve existing handling for other workspace loading paths.
- Around line 404-407: Strengthen external project validation in the URL
handling logic by requiring a trusted-origin policy, pinned content digest, or
cryptographic signature verification before parsing or executing remote project
JSON; retain same-origin handling and reject external content that cannot
satisfy the selected integrity check, rather than relying on HTTPS alone.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
| const url = new URL(projectPath, window.location.href); | ||
| if (url.origin !== window.location.origin && url.protocol !== "https:") { | ||
| throw new Error("External project URLs must use HTTPS"); | ||
| } |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
Apply this validation to every project fetch.
loadWorkspace still calls fetch(validatedUrl.href) at Lines 511-512 after allowing both http: and https:. That bypasses this HTTPS-only guard for ?project= URLs. Route that branch through fetchProjectJson(validatedUrl.href) or centralize the validator.
Suggested fix
- fetch(validatedUrl.href)
- .then(parseProjectJsonResponse)
+ fetchProjectJson(validatedUrl.href)🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@main/files.js` around lines 404 - 407, Update loadWorkspace so the ?project=
fetch path uses fetchProjectJson with validatedUrl.href instead of calling fetch
directly, ensuring every project fetch applies the HTTPS-only external URL
validation. Preserve existing handling for other workspace loading paths.
🔒 Security & Privacy | 🟠 Major | 🏗️ Heavy lift
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Files matching files.js:"
fd -a 'files\.js$' . || true
echo
echo "Relevant lines in main/files.js:"
sed -n '360,440p' main/files.js || true
echo
echo "Search for projectPath/url/project execution/loading:"
rg -n "projectPath|new URL\\(projectPath|\\.json|fetch\\(|loadProject|execute|eval\\(|import\\(" main/files.js main || trueRepository: flipcomputing/flock
Length of output: 9065
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Git status/stat:"
git status --short
git diff --stat || true
echo
echo "All files.js candidates:"
git ls-files '*files.js' '*files.jsx' '*files.tsx' | sed -n '1,80p'Repository: flipcomputing/flock
Length of output: 214
🌐 Web query:
MDN IntegrityAttribute crossorigin HTTPS secure transport integrity not provided subresource integrity
💡 Result:
Subresource Integrity (SRI) is a security feature that allows browsers to verify that fetched resources (such as scripts or stylesheets) are delivered without unexpected manipulation by comparing a provided cryptographic hash against the resource's actual content [1][2]. When using the integrity attribute for cross-origin resources, the crossorigin attribute must also be included [1][2]. This is a mandatory requirement for several key reasons: 1. CORS Enforcement: SRI requires the Cross-Origin Resource Sharing (CORS) protocol to ensure the resource owner explicitly permits the requesting origin to access the content [1][3]. If crossorigin is not provided, the browser defaults to no-cors mode, which restricts the requester's ability to read the response content [1]. Browsers will refuse to perform SRI validation on no-cors requests to prevent potential security vulnerabilities where an attacker could use integrity checks to infer information about cross-origin resources [1][3][4]. 2. Security Guarantee: The requirement to use CORS ensures that the resource is intentionally shared [4]. Without this explicit permission, allowing SRI validation on arbitrary cross-origin resources could allow attackers to bypass standard same-origin policy restrictions [3][4]. Regarding secure transport and HTTPS: While SRI is an application-level security tool and can technically be defined in a non-secure context (HTTP), it is strongly recommended that authors deliver integrity metadata only within a Secure Context (HTTPS) [3]. If a page is delivered over HTTP, an attacker can modify the document in-flight, including the integrity hash itself, rendering the SRI protection useless [3]. Therefore, using HTTPS is essential for ensuring that the integrity metadata remains trustworthy and that the subresource request itself is protected from man-in-the-middle attacks [2][3]. In summary, for cross-origin resources, you must provide both the integrity attribute (containing the hash) and the crossorigin attribute (to enable CORS), and you should always serve the content over HTTPS to ensure the integrity metadata is not tampered with [1][2][3].
Citations:
- 1: https://developer.mozilla.org/en-US/docs/Web/Security/Defenses/Subresource_Integrity
- 2: https://developer.mozilla.org/en-US/docs/Web/Security/Practical_implementation_guides/SRI
- 3: https://www.w3.org/TR/2016/REC-SRI-20160623/
- 4: https://www.w3.org/TR/sri/
HTTPS alone does not provide content integrity.
This only enforces HTTPS transport for non-same-origin URLs. A compromised HTTPS endpoint can still return malicious project JSON that gets parsed and executed, so add a trusted-origin policy, pinned digest, or cryptographic signature verification before executing external project content.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@main/files.js` around lines 404 - 407, Strengthen external project validation
in the URL handling logic by requiring a trusted-origin policy, pinned content
digest, or cryptographic signature verification before parsing or executing
remote project JSON; retain same-origin handling and reject external content
that cannot satisfy the selected integrity check, rather than relying on HTTPS
alone.
1 participant
Summary
Fix high severity security issue in
main/files.js.Vulnerability
V-001main/files.js:404Description: External API calls using fetch() lack integrity verification mechanisms. If an attacker compromises the external endpoints or performs a MITM attack, malicious code could be injected into fetched resources (project JSON, font files) and executed in the application context.
Evidence
Exploitation scenario: Compromise external API endpoint serving projectPath or fontUrl resources, or perform MITM attack to inject malicious JavaScript into fetched resources that gets executed in the application.
Scanner confirmation: multi_agent_ai rule
V-001flagged this pattern.Production code: This file is in the production codebase, not test-only code.
Threat Model Context
This is a Node.js library - vulnerabilities affect downstream consumers who use this package.
Changes
main/files.jsVerification
Automated security fix by OrbisAI Security
Summary by CodeRabbit