Skip to content

fix: external api calls using fetch() lack integrity... in files.js #722

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
anupamme wants to merge 1 commit into
base: main
Choose a base branch
from
Open

fix: external api calls using fetch() lack integrity... in files.js #722

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions main/files.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -401,6 +401,10 @@ function parseProjectJsonResponse(response) {
}

export function fetchProjectJson(projectPath) {
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");
}
Comment on lines +404 to +407

@coderabbitai coderabbitai Bot Jul 23, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔒 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 || true

Repository: 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:

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.

return fetch(projectPath).then(parseProjectJsonResponse);
}

Expand Down