File Upload Security Test Cases: Verify Every Boundary

A file upload can reject .exe files and still be insecure.

The server may trust a forged MIME type, preserve a user-controlled path, expose temporary objects before scanning completes, attach a file to the wrong tenant, or serve untrusted content from the application’s own origin.

In practice, the dangerous gap is often not the allowlist itself. It is the interval between accepting the bytes and deciding that the file may be processed, published, or retrieved.

A secure upload therefore needs more than one validation rule:

User authorised
→ request limits checked
→ source content validated
→ safe storage identity assigned
→ file isolated
→ security checks completed
→ ownership confirmed
→ controlled delivery enabled
→ retention policy enforced

The test should follow that complete path.

This guide covers the security controls that QA engineers can verify safely with controlled fixtures, browser automation, API tests, and authorised test environments. It does not provide weaponised payloads or instructions for exploiting parsers, web servers, antivirus products, or storage infrastructure.

For general behaviour such as progress, retry, cancellation, multiple files, and business-level processing, see File Upload Test Cases.

For image decoding, EXIF orientation, cropping, responsive variants, transparency, and metadata, see Image Upload Test Cases.

Start with the Security Contract

A secure upload policy must describe more than the permitted extensions.

Before building the test matrix, document why the product accepts each format, which components process it, where the file waits before approval, and who can retrieve it after publication.

A practical security completion rule is:

A file becomes publishable only after the uploader is authorised, the detected content matches an allowed business format, every mandatory security check has passed, the application has assigned a safe storage identity, and each retrieval path enforces the intended access and delivery policy.

Do not represent all intermediate states as Uploaded.

Use explicit states such as:

Rejected
Pending validation
Quarantined
Pending scan
Safe
Ready for processing
Published
Expired
Deleted

The distinction matters. A file may exist in temporary storage without being safe, publishable, or retrievable.

What QA Can Test Safely

A QA suite should prove that the documented controls work. It should not quietly turn a shared CI runner into an exploit laboratory.

Routine functional and integration tests can safely verify:

• server-side type validation;
• extension, MIME, and content mismatches;
• generated storage identities;
• filename normalisation;
• authentication and authorisation;
• tenant isolation;
• quarantine states;
• scanner success, rejection, timeout, and unavailability;
• blocked retrieval before approval;
• response content types and download headers;
• signed URL expiration;
• file, batch, quota, and archive limits;
• direct API calls that bypass the browser;
• retries, replacement, deletion, and cleanup;
• audit events.

A dedicated security assessment is more appropriate for:

• real malware;
• executable server-side payloads;
• weaponised office documents;
• parser exploitation;
• antivirus evasion;
• malicious polyglot research;
• decompression bombs;
• sandbox escape attempts;
• infrastructure-level bucket or container misconfiguration;
• race-condition exploitation against production-like infrastructure.

Not every case belongs in CI.

Filename, content-validation, ownership, quarantine, and delivery-policy checks should run regularly. Destructive archive and parser scenarios belong in an isolated environment owned jointly with the security team.

For routine automation, use inert fixtures that reproduce the required property without executing code.

Model the Secure Upload Pipeline

A secure upload is a gated state machine, not a direct path from the browser to public storage.

Unauthenticated
  └── Reject

Authenticated
  ↓
Authorised for the target record
  ├── Reject role, ownership, or tenant
  ↓
Request and quota limits checked
  ├── Reject size, count, rate, or storage limit
  ↓
Temporary isolated storage
  ↓
Filename normalised
  ↓
Safe storage identity assigned
  ↓
Extension policy checked
  ↓
Declared MIME evaluated
  ↓
Signature and content detected
  ↓
Full parser or decoder validation
  ├── Reject unexpected or corrupted content
  ↓
Quarantine
  ↓
Scanner or content analysis
  ├── Reject or hold suspicious content
  ├── Remain pending if the scanner is unavailable
  ↓
Ownership confirmed again
  ↓
Permanent storage or controlled processing
  ↓
Authorised delivery
  ↓
Expired, replaced, or deleted

The order is part of the security contract.

A scanner integration can be technically healthy and still provide little protection if a temporary URL is already public. Likewise, a safe generated object key does not help if the original filename later reappears inside an unvalidated download path.

The release-gating test should ask a narrow question:

Can untrusted bytes cross any boundary before the product has made and recorded its security decision?

Core File Upload Security Test Cases

Validate the Source and Assign a Safe Identity

Extension, browser-declared MIME type, file signature, and actual content are separate signals.

The browser controls the multipart filename and request content type. A signature may identify the beginning of a format, but it does not prove that the complete file is valid. Some formats require full decoding or specialised parsing before the application can trust them.

The original filename is also untrusted. Keep it for display when needed, but do not use it as the physical object key.

A safe model separates three values:

Display name:
customer-contract.pdf

Logical file ID:
file_7f23d91c

Storage object key:
tenant-a/2026/07/2de91d1e-6a7b-4bfd-a85e

This allows the product to preserve a friendly name without trusting it as a path.

For boundary variants such as extension case, double extensions, missing extensions, and trailing characters, a data-driven test is better than several nearly identical browser flows.

Authorise Every Upload and State Transition

Upload permission and file retrieval are separate authorisation decisions.

A user may be able to upload to one project but not another. A support agent may view an attachment without permission to replace it. A tenant administrator should not gain access to objects owned by another tenant, even if the identifier is predictable.

The browser UI is not the security boundary. Every relevant check must also run when the endpoint is called directly.

Direct-to-storage designs need special attention.

The storage provider may accept the bytes, while the application separately controls object creation, scan status, ownership, and final attachment. A test that proves only that the signed upload succeeded does not prove that the application accepted the file securely.

Validate again when the client reports completion:

Signed upload issued
→ object uploaded
→ object metadata inspected
→ size and ownership confirmed
→ scan requested
→ safe verdict recorded
→ attachment allowed

A pre-signed instruction should bind at least the intended object key, expiration, uploader context, and relevant size or policy constraints.

Quarantine and Release

The security property is not “the scanner was called.”

It is:

Untrusted object
→ isolated
→ analysed
→ decision recorded
→ only an approved result released

The file should remain inaccessible while any mandatory scanner or content-analysis result is pending.

A scanner result should be bound to immutable evidence such as the object ID, version, checksum, or another content identity used by the processing pipeline.

Otherwise, replacement and retry flows can accidentally inherit an old verdict.

The same rule applies to generated previews and derivatives. If the product creates a thumbnail before final approval, that thumbnail must remain isolated too.

Control Storage and Delivery

An allowed file can become dangerous when served incorrectly.

Risk changes depending on whether the browser renders the response inline, whether the object comes from the application origin, whether the content type is accurate, and whether caches can store a private response.

X-Content-Type-Options: nosniff is useful, but it is only one delivery control.

It does not replace:

• correct type detection;
• rejection of dangerous formats;
• storage isolation;
• authorisation;
• suitable Content-Disposition;
• safe preview generation;
• a separate delivery origin where needed.

Private responses also need an explicit cache policy. Hiding a URL in the interface does not make the object private.

Limit Files, Batches, Archives, and Processing

File size is only one resource boundary.

A small compressed image may expand into a large bitmap. An archive may contain thousands of entries. A valid document can trigger expensive preview generation. Many individually acceptable files can exceed a tenant quota when submitted together.

Use a compact boundary matrix for size and count rules:

Destructive archive testing should not run on a shared CI worker.

Use low-impact synthetic fixtures, service doubles, or a security-owned environment where CPU, memory, storage, and cleanup are controlled.

Retention, Audit, and Cleanup

A rejected file is still a stored object until the system removes it.

Security defects often appear after the visible workflow has ended: an orphan survives a failed attachment, a deleted object remains reachable through a CDN, or a late scanner event republishes a file whose business record no longer exists.

Logs should identify the decision without becoming another uncontrolled copy of user data.

Avoid logging:

• complete file contents;
• credentials;
• active signed URLs;
• unnecessary personal metadata;
• raw secrets included in document content.

A useful audit event may include:

{
  "event": "file_upload_rejected",
  "fileId": "file_7f23d91c",
  "actorId": "user_1042",
  "tenantId": "tenant_a",
  "decision": "reject",
  "reason": "content_type_mismatch",
  "detectedType": "text/plain",
  "declaredType": "application/pdf",
  "correlationId": "req_92f814",
  "occurredAt": "2026-07-29T15:12:33Z"
}

Evidence That the Controls Worked

A red validation message is not enough.

The test should prove that the rejected or pending file did not cross another boundary behind the interface.

A strong rejection test may look like this:

Upload inert mismatched content
→ server rejects the mismatch
→ no safe object is created
→ no business attachment exists
→ direct retrieval fails
→ the rejection is logged
→ temporary bytes are removed

A strong successful test proves the opposite path:

Upload controlled clean fixture
→ isolate it
→ validate the source
→ record a successful scan
→ confirm ownership
→ publish one object
→ permit the owner
→ reject another user
→ delete and revoke access

Security Failures That Look Safe

These patterns are valuable because they target false confidence.

The visible control may work exactly as designed while another storage, processing, or delivery path remains open.

Automate the Boundaries with Playwright

Playwright can test both sides of the feature:

• locator.setInputFiles() covers the visible upload journey;
• APIRequestContext calls the server directly and bypasses client-side validation.

Use controlled inert content. The goal is to verify the boundary, not execute a payload.

Reject Mismatched Content at the API Boundary

The following fixture claims to be a PDF through its name and MIME type but contains plain text.

import { test, expect } from '@playwright/test';

test('rejects content that does not match the declared PDF type', async ({
  page,
}) => {
  await page.goto('/documents');

  await page.getByLabel('Upload document').setInputFiles({
    name: 'quarterly-report.pdf',
    mimeType: 'application/pdf',
    buffer: Buffer.from(
      'Controlled inert fixture. This is not a valid PDF document.',
    ),
  });

  const [response] = await Promise.all([
    page.waitForResponse(
      candidate =>
        candidate.url().includes('/api/uploads') &&
        candidate.request().method() === 'POST',
    ),
    page.getByRole('button', { name: 'Upload' }).click(),
  ]);

  expect([400, 415, 422]).toContain(response.status());

  await expect(page.getByRole('alert')).toContainText(
    /invalid|unsupported|content|format/i,
  );

  await expect(page.getByTestId('uploaded-file')).toHaveCount(0);
});

Now bypass the browser:

import { test, expect } from '@playwright/test';

test('enforces type validation on direct multipart requests', async ({
  request,
}) => {
  const response = await request.post('/api/uploads', {
    multipart: {
      file: {
        name: 'quarterly-report.pdf',
        mimeType: 'application/pdf',
        buffer: Buffer.from(
          'Controlled inert fixture. This is not a PDF.',
        ),
      },
      businessRecordId: 'case-123',
    },
  });

  expect([400, 415, 422]).toContain(response.status());

  const body = await response.json();

  expect(body.code).toMatch(
    /INVALID_FILE|UNSUPPORTED_TYPE|CONTENT_MISMATCH/,
  );
});

The exact status and error code are application-specific.

The stable assertion is that browser metadata cannot make invalid content trusted.

Safe storage identity can be verified in the same API journey:

expect(upload.originalName).toBe('customer-contract.pdf');
expect(upload.storageKey).not.toContain('..');
expect(upload.storageKey).not.toContain('customer-contract.pdf');
expect(upload.storageKey).toMatch(/^[a-zA-Z0-9/_-]+$/);

Keep Pending Files Inaccessible

A clean response from the upload endpoint may create only a pending object.

import { test, expect } from '@playwright/test';

test('does not expose a file while security checks are pending', async ({
  request,
}) => {
  const uploadResponse = await request.post('/api/uploads', {
    multipart: {
      file: {
        name: 'document.pdf',
        mimeType: 'application/pdf',
        buffer: Buffer.from(
          '%PDF-1.4\n% controlled non-sensitive fixture\n',
        ),
      },
      businessRecordId: 'case-123',
    },
  });

  expect(uploadResponse.ok()).toBeTruthy();

  const upload = await uploadResponse.json();

  expect(upload.status).toMatch(
    /pending_validation|pending_scan|quarantined/,
  );

  const contentResponse = await request.get(
    `/api/files/${upload.id}/content`,
  );

  expect([403, 404, 409, 423]).toContain(contentResponse.status());
});

The endpoint may return 403, 404, 409, or 423. The precise status is less important than the security property: pending bytes cannot be retrieved as approved content.

For the successful path, poll the trusted source of truth rather than sleeping for a fixed duration:

await expect
  .poll(
    async () => {
      const response = await request.get(`/api/files/${upload.id}`);

      if (!response.ok()) {
        return `http-${response.status()}`;
      }

      return (await response.json()).status;
    },
    {
      message: 'file should reach the approved state',
      timeout: 30_000,
    },
  )
  .toBe('ready');

Scanner timeout and unavailability should be tested through a service stub, controlled test mode, or isolated integration environment. Do not attempt to break a shared scanner in CI.

Verify Ownership and Delivery Policy

Use separate authenticated API contexts to prove that ownership is enforced at retrieval.

import { test, expect, request as apiRequest } from '@playwright/test';

test('permits the owner and rejects another user', async () => {
  const ownerApi = await apiRequest.newContext({
    baseURL: 'https://test.example.com',
    extraHTTPHeaders: {
      Authorization: `Bearer ${process.env.OWNER_TEST_TOKEN}`,
    },
  });

  const otherUserApi = await apiRequest.newContext({
    baseURL: 'https://test.example.com',
    extraHTTPHeaders: {
      Authorization: `Bearer ${process.env.OTHER_USER_TEST_TOKEN}`,
    },
  });

  try {
    const uploadResponse = await ownerApi.post('/api/uploads', {
      multipart: {
        file: {
          name: 'private-note.txt',
          mimeType: 'text/plain',
          buffer: Buffer.from('Controlled private test content'),
        },
        businessRecordId: 'case-123',
      },
    });

    expect(uploadResponse.ok()).toBeTruthy();

    const upload = await uploadResponse.json();

    await expect
      .poll(async () => {
        const response = await ownerApi.get(`/api/files/${upload.id}`);

        if (!response.ok()) {
          return `http-${response.status()}`;
        }

        return (await response.json()).status;
      })
      .toBe('ready');

    const ownerDownload = await ownerApi.get(
      `/api/files/${upload.id}/content`,
    );

    expect(ownerDownload.ok()).toBeTruthy();

    const headers = ownerDownload.headers();

    expect(headers['content-type']).toBe('text/plain');
    expect(headers['content-disposition']).toMatch(
      /^attachment;\s*filename=/i,
    );
    expect(headers['x-content-type-options']).toBe('nosniff');

    const otherUserDownload = await otherUserApi.get(
      `/api/files/${upload.id}/content`,
    );

    expect([403, 404]).toContain(otherUserDownload.status());
  } finally {
    await ownerApi.dispose();
    await otherUserApi.dispose();
  }
});

Only require attachment when the product is supposed to download the file. Images, videos, and PDFs may intentionally render inline, but they still need the correct content type, ownership policy, cache policy, and origin strategy.

Use dedicated test accounts. Keep tokens in the CI secret store, and never hard-code real user credentials.

Build a Controlled Security Fixture Set

Random files from tester laptops do not create a reliable security suite.

Each fixture should represent one explicit property and have a documented expected decision.

tests/
└── fixtures/
    └── upload-security/
        ├── allowed/
        │   ├── valid-small.pdf
        │   ├── valid-text.txt
        │   └── valid-image.png
        ├── mismatches/
        │   ├── text-named-as-pdf.pdf
        │   ├── png-with-text-mime.png
        │   └── truncated-pdf.pdf
        ├── filenames/
        │   ├── duplicate-name.txt
        │   ├── unicode-name.txt
        │   ├── very-long-name.txt
        │   └── reserved-name.txt
        ├── boundaries/
        │   ├── exact-max.bin
        │   ├── max-plus-one.bin
        │   └── many-small-files/
        ├── archives/
        │   ├── allowed-small.zip
        │   ├── nested-directories.zip
        │   └── mixed-allowed-and-rejected.zip
        └── scanner/
            ├── approved-clean-fixture.bin
            └── approved-scanner-test-fixture.bin

Keep expectations in a manifest:

{
  "text-named-as-pdf.pdf": {
    "declaredMimeType": "application/pdf",
    "detectedType": "text/plain",
    "expectedDecision": "reject",
    "reason": "content_type_mismatch",
    "safeForSharedCi": true
  },
  "approved-scanner-test-fixture.bin": {
    "expectedDecision": "quarantine",
    "environment": "isolated-security-test",
    "owner": "security-team",
    "safeForSharedCi": false
  }
}

Fixture rules:

• use inert content in routine CI;
• version fixtures with the policy they test;
• never use customer uploads;
• keep security-team fixtures in controlled storage;
• document whether a fixture is safe for shared runners;
• remove temporary artifacts after execution;
• use separate owner, other-user, and other-tenant accounts;
• record the expected detected type, verdict, and terminal state;
• generate large boundary buffers when committing binaries is unnecessary.

For example:

const maximumBytes = 5 * 1024 * 1024;

const exactMaximum = Buffer.alloc(maximumBytes, 0x61);
const oneByteOver = Buffer.alloc(maximumBytes + 1, 0x61);

Avoid generating many large buffers concurrently across test workers.

The Release-Gating Security Journey

Do not begin by automating all 102 checks as separate browser scripts.

Start with one clean fixture and one controlled mismatch. Prove the critical boundaries first.

The release-gating path should demonstrate that:

1. an authorised user can upload a permitted clean fixture;
2. an unauthorised user cannot upload to the same business record;
3. an extension or MIME mismatch does not bypass server validation;
4. the application generates an independent storage identity;
5. the file remains inaccessible while validation or scanning is pending;
6. only an approved verdict permits publication;
7. the owner can retrieve the ready file;
8. another user and another tenant cannot retrieve it;
9. delivery headers match the intended inline or attachment policy;
10. retry creates one logical file rather than a duplicate;
11. replacement returns to quarantine;
12. deletion removes retrieval access;
13. rejected and expired temporary objects are cleaned;
14. the audit trail records the security decision.

Once that path is reliable, vary the data:

• role;
• tenant;
• extension;
• declared MIME type;
• detected content;
• filename;
• file size;
• batch count;
• quota state;
• scan result;
• scanner availability;
• object version;
• delivery origin;
• signed URL lifetime;
• retention state.

With WrightTest, the visible upload flow can remain stable while the account, fixture, request metadata, security result, and expected terminal state change.

The goal is not to build an automated exploit library. It is to prove that each documented boundary continues to reject, quarantine, isolate, or authorise a file exactly where the product says it should.

Sources

• OWASP File Upload Cheat Sheet
• OWASP Input Validation Cheat Sheet
• OWASP Web Security Testing Guide: Test Upload of Unexpected File Types
• OWASP Web Security Testing Guide: Test Upload of Malicious Files
• OWASP ASVS 5.0: File Upload and Content
• MITRE CWE-434: Unrestricted Upload of File with Dangerous Type
• PortSwigger Web Security Academy: File Upload Vulnerabilities
• MDN: X-Content-Type-Options
• MDN: Content-Disposition
• Playwright: Locator.setInputFiles
• Playwright: APIRequestContext