From f459922ad7283df9bf61769fc3eb4e5e13caf2b4 Mon Sep 17 00:00:00 2001
From: "google-labs-jules[bot]"
 <161369871+google-labs-jules[bot]@users.noreply.github.com>
Date: Sat, 28 Mar 2026 04:02:05 +0000
Subject: [PATCH] =?UTF-8?q?=F0=9F=9B=A1=EF=B8=8F=20Sentinel:=20[CRITICAL]?=
 =?UTF-8?q?=20Fix=20IDOR=20in=20file=20deletion?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: xb1g <70068561+xb1g@users.noreply.github.com>
---
 .jules/sentinel.md      | 7 ++++++-
 app/api/upload/route.ts | 4 +++-
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/.jules/sentinel.md b/.jules/sentinel.md
index 08e5bfbd..ccf2f7e9 100644
--- a/.jules/sentinel.md
+++ b/.jules/sentinel.md
@@ -6,4 +6,9 @@
 ## 2025-03-08 - Unsafe SVG Rendering via dangerouslySetInnerHTML
 **Vulnerability:** User-controlled SVG strings (`avatar.svg_data`) were being injected directly into the DOM using `dangerouslySetInnerHTML`. An attacker could inject an SVG containing embedded malicious `<script>` tags or `onload` event handlers, leading to Stored Cross-Site Scripting (XSS).
 **Learning:** Rendering raw SVGs inline is inherently dangerous. SVGs are essentially XML documents capable of embedding JavaScript.
-**Prevention:** When you need to display user-provided SVGs and you don't need to manipulate their internal paths via CSS/JS, do not use `dangerouslySetInnerHTML`. Instead, render the SVG securely by encoding it as a data URI (`data:image/svg+xml;charset=utf-8,${encodeURIComponent(svgData)}`) and using it as the `src` attribute of a standard `<img>` tag. This forces the browser to treat the SVG strictly as an image, entirely disabling any embedded script execution.
\ No newline at end of file
+**Prevention:** When you need to display user-provided SVGs and you don't need to manipulate their internal paths via CSS/JS, do not use `dangerouslySetInnerHTML`. Instead, render the SVG securely by encoding it as a data URI (`data:image/svg+xml;charset=utf-8,${encodeURIComponent(svgData)}`) and using it as the `src` attribute of a standard `<img>` tag. This forces the browser to treat the SVG strictly as an image, entirely disabling any embedded script execution.
+
+## 2025-03-08 - IDOR Vulnerability in File Deletion via string.includes()
+**Vulnerability:** In `app/api/upload/route.ts`, the `DELETE` endpoint used `fileName.includes('submissions/${user.id}/')` to verify that the file being deleted belonged to the requesting user. Since cloud storage keys (like S3/B2) are treated as literal strings, an attacker could theoretically bypass this by constructing a key that contains their user ID as a substring (e.g., `other-user/submissions/${attacker_id}/target-file.jpg`).
+**Learning:** `string.includes()` is an inherently weak authorization check for hierarchical paths because it matches anywhere in the string.
+**Prevention:** Always use exact string matching or prefix matching (`.startsWith()`) when verifying ownership via path keys to enforce strict hierarchical boundaries.
\ No newline at end of file
diff --git a/app/api/upload/route.ts b/app/api/upload/route.ts
index 56d019c7..db714ec3 100644
--- a/app/api/upload/route.ts
+++ b/app/api/upload/route.ts
@@ -75,7 +75,9 @@ export async function DELETE(request: NextRequest) {
       return NextResponse.json({ error: "Valid fileName is required" }, { status: 400 });
     }
 
-    if (!fileName.includes(`submissions/${user.id}/`)) {
+    // 🛡️ SECURITY: Use startsWith() instead of includes() to prevent path traversal/IDOR.
+    // An attacker could bypass includes() by naming a file like `otheruser/submissions/${user.id}/file.ext`
+    if (!fileName.startsWith(`submissions/${user.id}/`)) {
       return NextResponse.json({ error: "Access denied" }, { status: 403 });
     }