How a Missing MIME Type Caused a Stored Frontend Denial of Service

Affected endpoint:

POST /api/naivedyam/api/v1/feedback/

I removed the Content-Type header from the uploaded file part. The backend still accepted the request and stored the feedback with:

{
  "document_mimetype": null
}

{
  "document_mimetype": null
}

When users later opened the Feedback page, the frontend attempted to process this value as a string, likely using logic such as:

feedback.document_mimetype.toLowerCase()

feedback.document_mimetype.toLowerCase()

Because the value was null, JavaScript threw a runtime error and the page displayed a blank white screen.

Since the malformed record was stored in the database, the issue affected all users and roles accessing the feedback view until the record was corrected or deleted.

Impact

A single modified upload caused a stored frontend denial of service:

Missing Content-Type → NULL MIME type stored → frontend crash → Feedback page unavailable

Root Cause

The backend accepted invalid file metadata, while the frontend assumed that document_mimetype would always be a valid string.

Recommended Fix

Backend:

• Reject files with missing MIME types.
• Validate file extensions and actual file content using an allowlist.
• Prevent NULL values for required metadata.
• Clean up existing malformed records.

Frontend:

const mimeType =
  typeof feedback.document_mimetype === "string" &&
  feedback.document_mimetype.trim()
    ? feedback.document_mimetype.toLowerCase()
    : "application/octet-stream";

const mimeType =
  typeof feedback.document_mimetype === "string" &&
  feedback.document_mimetype.trim()
    ? feedback.document_mimetype.toLowerCase()
    : "application/octet-stream";

The UI should show a generic file icon or "Unknown file type" instead of crashing.

Key Lesson

File metadata is user-controlled input. Backend validation, database constraints, and defensive frontend rendering are necessary to ensure that one malformed record cannot take down an entire page.