OWASP Juice Shop File Challenges: file-434, FTP & Backup Secrets

OWASP Juice Shop contains several challenges that revolve around finding and accessing sensitive files that should not be publicly available — from a misconfigured FTP directory listing to confidential acquisition documents, developer backup files, and even hidden Easter eggs embedded in the application. These challenges teach the real-world vulnerability class of sensitive data exposure through insecure file access, which is consistently found in production web application security assessments.

This guide covers the file-related challenges in Juice Shop, how to solve them, and what real-world vulnerability patterns each one represents.

---

Why File Exposure Challenges Matter

Before diving into the solutions, it is worth understanding why Juice Shop includes so many file-related challenges. In real enterprise web applications, exposed files are an extremely common source of high-severity findings:

• Directory listings on web servers expose complete file lists to anyone who knows to look
• Forgotten backup files (.bak, .old, .zip, ~ suffixes) are often left in web roots after migrations
• Confidential documents uploaded to accessible storage paths without authentication requirements
• Source maps (.js.map files) reveal decompiled JavaScript source to anyone who inspects network traffic
• Package manifests committed to accessible directories reveal exact dependency versions for SCA analysis by attackers

Each Juice Shop file challenge mirrors a pattern found in real security assessments. Completing them builds the methodical enumeration skills needed to find these issues in production applications.

---

What Is the file-434 Challenge in Juice Shop?

If you searched for “file-434” specifically, you may have encountered this string as a Juice Shop challenge token or in a community write-up. In Juice Shop’s challenge tracking system, file-434 is the internal identifier for the “Confidential Document” challenge — the challenge that involves accessing a sensitive PDF or markdown file through the exposed /ftp/ directory listing.

Some CTF platforms and Juice Shop challenge exports reference challenges by these numeric IDs (e.g., file-434, xss-1, sqli-3) rather than their friendly names. If you are using a CTF platform integration (CTFd, FBCTF) with the Juice Shop CTF CLI, challenge IDs in this format may appear in the challenge configuration export.

To solve the file-434 / Confidential Document challenge: navigate to http://localhost:3000/ftp/ and download acquisitions.md. Full details in the section below.

---

The /ftp/ Directory: Juice Shop’s Open File Server

The Challenge: Confidential Document

Difficulty: ⭐ (1 star)
Category: Sensitive Data Exposure

One of Juice Shop’s most accessible — and most instructive — challenges involves the /ftp/ directory. Navigate to:

http://localhost:3000/ftp/

You will find an HTTP directory listing — a web server configuration error that exposes the complete contents of a directory to any visitor. In a real web application, directory listings are typically the result of Apache Options +Indexes, Nginx autoindex on, or an S3 bucket with ListBucket permission granted to public.

The /ftp/ directory contains several files. Downloading acquisitions.md completes the “Confidential Document” challenge:

http://localhost:3000/ftp/acquisitions.md

What this teaches: In real engagements, checking /backup/, /files/, /documents/, /uploads/, and similar common paths is standard enumeration practice. Tools like ffuf and gobuster automate this directory brute-forcing. A single confidential document — a financial report, an acquisition memo, customer data export — found in a publicly accessible path is a critical-severity finding in any security assessment.

The real-world fix: Disable directory listing on the web server (Options -Indexes in Apache, remove autoindex in Nginx), ensure all uploaded files are stored outside the web root or behind authentication, and audit S3/Azure Blob/GCS bucket permissions.

---

The Backup File: Null Byte Injection

The Challenge: Forgotten Developer Backup

Difficulty: ⭐⭐⭐⭐ (4 stars)
Category: Sensitive Data Exposure

The /ftp/ directory also contains a file named package.json.bak — a backup of the application’s npm package manifest. Downloading .bak files directly from /ftp/ is blocked by a file extension filter that rejects requests for anything except specific allowed extensions.

The challenge: access package.json.bak despite the extension filter.

The technique: null byte injection

The server-side filter checks the file extension by looking for disallowed extensions in the filename. The null byte character (%00) terminates strings in some server-side languages and frameworks — causing the filter to evaluate the filename as ending before the .bak suffix:

http://localhost:3000/ftp/package.json.bak%2500.md

Breaking this down:

• %25 is URL-encoded %
• %2500 decodes to %00 (a null byte)
• .md is an allowed extension that the filter sees
• The server’s file system sees package.json.bak and serves it

This completes the “Forgotten Developer Backup” challenge.

What the file contains: package.json.bak reveals the exact npm dependency versions used by Juice Shop’s Node.js backend. In a real application, this information lets an attacker identify specific dependency versions, cross-reference them against CVE databases (NVD, GitHub Security Advisories), and target known vulnerabilities in the exact package versions deployed.

What this teaches: Null byte injection (CWE-158) exploits assumptions about string termination in hybrid environments where a high-level language (Node.js, PHP, Python) passes filenames to lower-level system calls that treat null bytes as string terminators. This was more prevalent in older PHP applications (C-based string handling) but still appears in systems with mixed-language file handling.

The real-world fix:

• Never store backup files in web-accessible directories
• Use an allowlist (not a blocklist) for permitted file types
• Normalize and validate file paths server-side before filesystem operations
• Store application dependencies in package-lock files or equivalent, committed to version control — there is no need for a .bak of package.json to exist in a web directory

---

The Easter Egg File

The Challenge: Easter Egg (Zero Stars)

Juice Shop contains an Easter egg hidden in its /ftp/ directory — a file called eastere.gg. This is a Base64-encoded message from the Juice Shop development team. Accessing it requires:

1. Finding the file in the FTP directory listing
2. Recognizing that the .gg extension is not blocked
3. Decoding the Base64 contents to reveal the hidden message

# Retrieve the egg
curl http://localhost:3000/ftp/eastere.gg

# Decode the contents
echo "[base64_contents_here]" | base64 -d

This challenge teaches the practice of examining every accessible resource — not just obvious targets — during a security assessment. Easter eggs left by developers occasionally contain more than humor: comments about credentials, internal system names, or infrastructure details useful to an attacker.

---

Source Map Exposure

The Challenge: Retrieve Source Code from Source Maps

Difficulty: ⭐⭐⭐⭐ (4 stars)
Category: Security Misconfiguration

Juice Shop ships its Angular frontend as a compiled JavaScript bundle. In development mode, or when a developer mistakenly enables source maps in production, .map files are generated alongside the compiled JavaScript. These source maps allow browsers to reconstruct the original TypeScript source code from the minified bundle.

The challenge involves retrieving the source map and using it to read Juice Shop’s original TypeScript source.

How to find and use source maps:

1. Open browser DevTools → Network tab
2. Navigate to http://localhost:3000/
3. Look for .js files in the network waterfall
4. Check whether .js.map files are accessible:

curl -I http://localhost:3000/main.js.map
# If HTTP 200: source maps are exposed

4. Once you have the source map, browser DevTools can use it automatically. You can also use the source-map npm package to extract the original source:

npm install -g source-map
# Extract original sources

What this teaches: Production applications should never expose source maps publicly. Source maps reveal the complete, readable source code of your frontend application — including any logic, hardcoded values, API endpoint paths, or commentary that developers assumed was hidden in minified code. In real assessments, checking for exposed source maps is a standard reconnaissance step when testing SPAs.

The real-world fix: Set your bundler (webpack, Vite, esbuild) to not generate source maps in production, or to generate them at a path not accessible from the web root. For internal debugging, consider server-side error tracking tools that can symbolicate error stack traces without exposing source maps to the public.

---

The Robots.txt and Sitemap: Free Enumeration

Before directly attacking file paths, real-world assessors always check:

http://localhost:3000/robots.txt
http://localhost:3000/sitemap.xml

Juice Shop’s robots.txt reveals paths the application tells search engine crawlers not to index — which often reveals sensitive paths precisely because an application is trying to hide them. The Disallow: entries in robots.txt are a roadmap of interesting paths to investigate.

This is not a specific Juice Shop challenge but represents best-practice reconnaissance methodology. In production applications, robots.txt sometimes discloses:

• Admin panel paths (/admin/, /_internal/, /staff/)
• API documentation paths (/api-docs/, /swagger/)
• Development tooling paths (/debug/, /.well-known/)
• Staging or backup directories

---

API Response Enumeration: Finding Hidden Files Through API Calls

The Challenge: Access the Administration Section

When you make authenticated API calls to Juice Shop’s REST API, responses frequently include more data than the UI displays. One technique for discovering hidden paths:

1. Open browser DevTools → Network tab
2. Log in to your Juice Shop account
3. Watch for API calls to navigation or menu endpoints
4. Examine the JSON response carefully

The API response for the navigation structure includes route definitions for all Angular application routes — including paths not linked from the main navigation menu. This reveals:

• /#/administration — the administration panel
• /#/score-board — the challenge scoreboard
• Other hidden routes

What this teaches: APIs frequently return complete data models to the frontend and rely on the UI to hide options that shouldn’t be used. An attacker who reads API responses directly — not through the UI — sees the complete data, including paths and options the UI intentionally does not expose. This is security through obscurity: the paths exist and work, they just aren’t linked.

In real REST API assessments, examining every API response for undocumented paths, IDs, and data fields is standard practice. OpenAPI/Swagger definitions, if accessible, provide a complete map of every endpoint.

---

File Upload Challenges

The Challenge: Upload Size

Difficulty: ⭐⭐⭐ (3 stars)
Category: Improper Input Validation

Juice Shop allows users to upload a profile picture. The file upload form applies a client-side size restriction — preventing files larger than 100KB from being selected in the browser’s file picker. The challenge: upload a file that exceeds the limit anyway.

The bypass: Client-side restrictions are never security controls. They can be bypassed by:

1. Using a command-line HTTP client that doesn’t enforce the browser restriction:

# Generate a large file
dd if=/dev/urandom of=large_file.jpg bs=1M count=10

# Upload directly via curl — bypasses all client-side restrictions
curl -X POST \
  -H "Authorization: Bearer [your_jwt_token]" \
  -F "file=@large_file.jpg;type=image/jpeg" \
  http://localhost:3000/profile/image/file

2. Intercepting the upload request in a proxy tool (Burp Suite) and modifying the file content after the browser accepts the file

What this teaches: File upload restrictions must be enforced server-side. Client-side validation improves user experience — it is not a security control. A server that accepts any file as long as the browser sends it is vulnerable to oversized file uploads (denial-of-service), MIME type spoofing, malicious file uploads, and other file upload vulnerabilities (CWE-434).

The Challenge: Upload Type

Difficulty: ⭐⭐⭐ (3 stars)
Category: Improper Input Validation

Related to the size challenge: the profile image upload only allows image files. The challenge involves uploading an XML file to the endpoint instead. Again, the client-side MIME type restriction is bypassed by direct API access:

curl -X POST \
  -H "Authorization: Bearer [your_jwt_token]" \
  -F "file=@payload.xml;type=image/jpeg" \
  http://localhost:3000/profile/image/file

By setting the Content-Type of the file part to image/jpeg even though the file is XML, the client-side filter is deceived. The server-side validation — if any — must independently verify the actual file content.

---

The /api-docs/ Path: Documentation Exposure

Juice Shop exposes its Swagger API documentation at:

http://localhost:3000/api-docs/

This is not hidden. The challenge insight is recognizing that the API documentation reveals every endpoint — including endpoints not exposed through the frontend UI. Reviewing api-docs reveals:

• All REST API endpoints (GET, POST, PUT, DELETE)
• Request body schemas
• Authentication requirements for each endpoint
• Endpoint parameters — including ID fields susceptible to IDOR attacks

In production security assessments, finding accessible API documentation (/swagger.json, /api-docs, /openapi.yaml, /.well-known/openapi) is a significant reconnaissance win — it provides a complete map of the application’s attack surface without requiring any active enumeration.

---

Summary: File-Related Vulnerabilities in Juice Shop

Challenge	Technique	Real-World Pattern
Confidential Document	Directory listing	Exposed S3 buckets, unsecured file servers
Forgotten Developer Backup	Null byte injection	Backup files in web roots
Easter Egg	File enumeration	Developer comments exposing sensitive info
Source Maps	Source code exposure	Source maps in production JS builds
Upload Size	Client-side bypass	Unrestricted file upload size
Upload Type	MIME type spoofing	Unvalidated file type uploads
API-docs exposure	API enumeration	Swagger/OpenAPI in production

Each of these patterns is found in real enterprise applications during security assessments. The Juice Shop implementations are straightforward versions of the same vulnerability class — the production versions are more complex but follow identical attack logic.

---

Detecting File Exposure Vulnerabilities with DAST

Automated DAST scanners should detect several of the file exposure patterns in Juice Shop:

• Directory listing — a good DAST scanner probes common paths and flags HTTP directory listings
• Sensitive file exposure — /robots.txt, /sitemap.xml, /.git/, /backup/, and common backup file extensions
• Source map exposure — checking for .js.map, .css.map files alongside compiled assets
• API documentation exposure — probing for /swagger.json, /api-docs, /openapi.yaml
• Unrestricted file upload — testing file upload endpoints with oversized files and unexpected MIME types

Offensive360 DAST tests all these patterns on every endpoint during a scan and reports file exposure findings with the exact URL, HTTP response code, and recommendation. Book a demo to see authenticated DAST scanning against your own application.

For detecting insecure file handling in source code — path traversal (CWE-22), unrestricted file upload (CWE-434), null byte handling — Offensive360 SAST performs deep taint analysis tracking file path construction from user-controlled input through filesystem operations.

---

Next Steps in Juice Shop

After completing the file-related challenges, the natural progression is:

• Access Control challenges — explore IDOR and admin section access (builds on what you found in /ftp/ and /api-docs/)
• Injection challenges — SQL injection in the login form and search bar
• XSS challenges — reflected and stored XSS using the techniques learned from client-side bypass

For the complete challenge walkthrough guide, see our OWASP Juice Shop challenge solutions. For the full scoreboard guide with all 100+ challenges by category and difficulty, see the Juice Shop scoreboard guide.

---

Offensive360 DAST benchmarks scanner coverage against OWASP Juice Shop on every release — including file exposure, injection, XSS, and access control categories. Book a demo to see live results against your own application.