File Handling Auditing

​

Audit objectives (high-level)

• Use a whitelist for allowed file types (explicit allow list).
• Enforce file size and file count limits.
• Sanitize or generate safe filenames to prevent path traversal and unsafe characters.
• Integrate anti-virus / content inspection in upload pipelines for hostile content.
• Store uploads outside the webroot; serve them via a safe, controlled channel.
• Prevent uploaded content from being executed.
• Validate MIME types and verify file signatures (“magic numbers”) where feasible.
• Inspect image and archive libraries for known vulnerabilities and pin versions.
• Implement protections against archive-based attacks (ZIP bombs, tar bombs).

​

Example audit prompt

* Welcome to Claude Code!

/help for help, /status for your current setup

cwd: /Users/jeremy/Repos/Claude Code Course/Express-login-demo

> Review all file upload functionality:

Check for:
1. File type validation (whitelist, not blacklist)
2. File size limits
3. Filename sanitization
4. Anti-virus scanning integration
5. Storage location (outside webroot)
6. Direct execution prevention
7. MIME type validation
8. Magic number verification
9. Image manipulation library vulnerabilities
10. ZIP bomb protection

Provide recommendations for secure file handling.

## Provide:

A structured finding report with the following for each issue:

Title, Severity (Critical/High/Medium/Low), CWE (if applicable), Evidence (file, function, line ranges), and a short Why it matters.

Exploitability notes and, where safe, a minimal PoC or reproduction steps (no real secrets).

Remediation: precise code-level fix or config change (snippets welcome), plus defense-in-depth guidance.

A summary risk score (0–10) and top 3–5 prioritized fixes that reduce risk fastest.

A checklist diff: which items from the "Check for" list are Pass/Fail/Not Applicable.

## Constraints & style:

Be concrete and cite exact code locations and identifiers.

​

Key concepts explained

​

Whitelisting vs. blacklisting

• Whitelist: explicitly allow only known-safe types (e.g., JPEG, PNG, PDF). This is the recommended approach.
• Blacklist: try to block known-bad types (e.g., .exe, .sh). Blacklists are error-prone and can miss novel threats.

​

Filename sanitization

• Normalize filenames and remove path separators and control characters.
• Consider generating server-side filenames (UUIDs) and storing the original name in metadata for display only.
• Deny user-controlled paths when writing files.

​

Anti-virus / content inspection

• Enterprise systems often route uploads through AV/IDS/IPS or content inspection services before storing or processing.
• If you cannot scan at upload time, mark files as untrusted and delay processing until they are inspected.

​

ZIP bombs and archive attacks

• A ZIP bomb is a small archive that expands into an extremely large set of files or a very large file, exhausting disk/memory.
• Mitigations: limit decompressed size, limit recursion/levels, validate file types and sizes inside archives before extraction.

​

Example audit findings (for this repository)

• The Express Login Demo application only handles JSON authentication requests and does not implement file uploads (no Multer, no express-fileupload, no multipart/form-data handling found).
• Because there is no upload functionality present, the file-upload risk score for this codebase is 0/10 for this assessment.
• A full audit report has been saved to /audits/FILE_UPLOAD_SECURITY_AUDIT.md with checklist results set to N/A where appropriate, and recommendations for secure implementation if uploads are added.

**Audit Date:** 2025-08-21  
**Application:** Express Login Demo  
**Scope:** File upload functionality security assessment  
**Auditor:** Claude Code Security Assessment

## Executive Summary

**Finding:** No file upload functionality present in the application.

The Express Login Demo application does not implement any file upload capabilities. The application is a simple authentication-only service with a single login endpoint that accepts JSON credentials.

## Risk Assessment

**Overall Risk Score:** 0/10 (No file upload functionality present)

Since there is no file upload functionality in the application, there are no file upload-related security vulnerabilities to address.

## Detailed Analysis

- Detailed analysis of the current architecture
- Security checklist results (all N/A due to no file upload functionality)
- Comprehensive recommendations for secure implementation if file uploads are added in the future
- Example code snippets for proper file validation, sanitization, and security controls

​

Secure defaults: example in Express using Multer

const path = require('path');
const multer = require('multer');

const upload = multer({
  dest: '/app/uploads/', // ensure this path is outside the webroot and not served by static middleware
  limits: {
    fileSize: 5 * 1024 * 1024, // 5 MB limit
    files: 1
  },
  fileFilter: (req, file, cb) => {
    // Whitelist approach: allow only these MIME types and extensions
    const allowedTypes = ['image/jpeg', 'image/png', 'application/pdf'];
    const allowedExtensions = ['.jpg', '.jpeg', '.png', '.pdf'];

    const ext = path.extname(file.originalname).toLowerCase();

    if (allowedTypes.includes(file.mimetype) && allowedExtensions.includes(ext)) {
      cb(null, true);
    } else {
      cb(new Error('Invalid file type'), false);
    }
  }
});

• Client-provided MIME types and extensions can be spoofed. Always verify file signatures (“magic numbers”) server-side, especially for high-risk types.
• For any image processing, limit dimensions and validate images before processing.
• Consider scanning files with an anti-virus engine or sandboxing them before further processing.

​

Defense-in-depth checklist (recommended controls)

• Whitelist MIME types + extension + magic number verification.
• Enforce file size and file count limits.
• Store uploads outside webroot and deny execution.
• Sanitize or generate server-side filenames.
• Scan uploads for malware where possible.
• Serve uploads from a separate domain/subdomain with strict headers (CSP, X-Content-Type-Options, X-Frame-Options).
• Limit and pin versions of image manipulation libraries.
• Validate archives before extraction; limit decompressed size and recursion depth.

​

Example checklist diff for this repository

​

Links and references

• Express — web framework
• Multer — middleware for handling multipart/form-data
• Kubernetes Basics — general platform context
• Docker Hub — container images
• Terraform Registry — infrastructure as code modules

• This repository currently contains no file upload functionality; therefore, the file-upload risk in this assessment is minimal (0/10).
• If uploads are introduced, follow the checklist and secure Multer example above, and require an audit to validate the implementation and deployment configuration.