Fix path traversal vulnerability in storage service content endpoint

[google-labs-jules]

Why are these changes being introduced?

A security vulnerability was identified in the storage service's content delivery endpoint (/content/:filename). Attackers could exploit this endpoint by using relative path traversal sequences (e.g., ../../etc/passwd) to escape the intended storage root directory and read sensitive system files on the host machine.

To resolve this, we needed to reorder the path resolution sequence. By fully constructing the target file path before validation, we can reliably verify if the resolved path resides within the authorized base directory (UPLOAD_DIR). Any attempts to escape the root directory using path traversal sequences are now caught and blocked before any file system reads occur.

Key Decisions & Rationale

• Validation After Resolution: Combining the base directory, sub-paths, and the user-supplied filename into a unified path first ensures that any .. segments are evaluated by the system. Checking the final, absolute path prevents attackers from tricking the validation logic with clever path segment positioning.
• Zero-Exposure Errors: If validation fails, the service returns a standard 400 Bad Request without exposing internal host file paths, adhering to secure coding guidelines.
• No Extra Dependencies: The fix relies entirely on existing path-handling logic and the standard safeResolve() utility to ensure zero performance degradation and minimize regression risks.

What has changed?

my-portfolio/server/storage-service/index.js

• Reordered the endpoint logic for /content/:filename to join the file paths into a rawPath initially.
• Integrated the existing safeResolve() utility to validate that the resolved path strictly starts with the authorized base directory.
• Implemented error handling that aborts the request and returns a 400 status code if validation fails.

Verification Results

• Legitimate Access: Verified that assets located inside valid sub-folders of the storage root are served without interruption.
• Attack Prevention: Confirmed that traversal attacks (e.g., requesting /content/../../etc/passwd) are successfully blocked with a 400 response and do not expose internal paths or server-side logs.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
sparkpage	Ready	Preview, Comment	Jul 15, 2026 5:14pm