Securing File Uploads and Downloads in E2E Tests

1. Why file interactions form their own testing category

File uploads and downloads differ from most other frontend interactions in that they involve the test environment's actual file system, not just the browser: an upload reads a real file from disk, a download writes a real file back, and both operations can take considerably longer than an ordinary form interaction depending on file size, network speed, and server configuration.

This extra dimension means a test that genuinely wants to secure file interactions can't only check the UI level, it also needs to keep actual test files in various sizes and formats on hand, tune the test runner's timeout behavior to realistic upload times, and inspect downloaded files' content directly within the test environment's file system.

An often overlooked organizational aspect is the need to reliably clean up temporary test download directories after every test run, since otherwise downloaded test files quietly accumulate across many CI runs and can, in the worst case, exhaust the CI runner's available disk space, which is why a clean test setup either empties the download directory before every test run or uses a fresh, temporary directory per run.

2. Automating file uploads with Playwright

Playwright offers setInputFiles as a direct way to hand one or more files to a file input field, without needing to open the operating system's native file dialog, which wouldn't be controllable from a browser test anyway, since it lies outside the area the browser controls.

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

test('product image upload in the admin works', async ({ page }) => {
  await page.goto('/admin/catalog/product/edit/id/123');
  const fileInput = page.locator('input[type="file"]');
  await fileInput.setInputFiles(path.join(__dirname, 'fixtures', 'product-image.jpg'));

  await expect(page.locator('[data-testid="upload-preview"]')).toBeVisible();
  await expect(page.locator('[data-testid="upload-filename"]')).toHaveText('product-image.jpg');
});

3. Deliberately testing large files and timeout behavior

An upload test that only works with a tiny sample file doesn't cover the most important real error sources, since issues with the upload size limit, slow progress indication, or a server-side timeout only become visible with actually large files, which is why a robust test strategy deliberately exercises a file just below and a file just above the configured size limit.

For the file just above the limit, the test expects a clear, understandable error message instead of a silent failure or an opaque server error, while for the large but still allowed file, the test additionally checks whether a progress indicator actually shows up during the upload and whether the whole operation completes successfully within a realistically sized, not overly tight timeout.

4. Checking file type validation on the client and server side

Complete file type validation consists of two separate layers that both need testing individually: a client-side pre-check that gives the user immediate feedback without server contact, and a server-side check that acts as the actual security boundary, since the client-side check can be fully bypassed via direct API calls without a browser.

An especially important test case is a file whose extension fakes an allowed category but whose actual binary content matches a different, disallowed file type, say a PHP file renamed to .jpg, since validation relying exclusively on the file extension instead of the actual file content represents a serious security risk that a deliberate, automated test case can reliably monitor in Magento admin upload areas.

test('a PHP file disguised as JPG gets rejected server-side', async ({ page, request }) => {
  await page.goto('/admin/catalog/product/edit/id/123');
  const fileInput = page.locator('input[type="file"]');
  await fileInput.setInputFiles(path.join(__dirname, 'fixtures', 'malicious.php.jpg'));

  await expect(page.locator('[data-testid="upload-error"]')).toContainText('File type not allowed');
});

5. Intercepting downloads in the test runner

Playwright provides its own event for downloads, triggered as soon as the browser downloads a file, letting the test wait for the download to finish and then determine the downloaded file's local path within the test environment's file system, without having to manually monitor a download folder itself.

test('an invoice PDF can be downloaded from the customer account', async ({ page }) => {
  await page.goto('/sales/order/history');

  const [download] = await Promise.all([
    page.waitForEvent('download'),
    page.locator('[data-testid="invoice-download"]').first().click(),
  ]);

  const filePath = await download.path();
  expect(download.suggestedFilename()).toMatch(/^invoice-\d+\.pdf$/);
  expect(filePath).toBeTruthy();
});

6. Validating downloaded file content

The mere presence of a downloaded file says nothing about its actual content, which is why a genuinely robust test then opens the downloaded file with a suitable parsing library and checks concrete, substantive expectations, say whether a downloaded CSV file contains the expected number of rows and columns or whether a downloaded PDF document contains the correct order number and invoice amount.

For PDF files, a text extraction library makes the contained text searchable, while for CSV and Excel exports a structured parsing library exposes individual cells as values directly instead of raw text, letting assertions be formulated precisely against specific, concrete data points rather than settling for an imprecise full-text search across the entire file content.

Beyond checking individual data points substantively, it's worth adding a simple checksum check across the entire file for especially critical downloads, say an invoice with legal relevance, to make sure the downloaded file wasn't corrupted by a faulty transfer, even when the individual content assertions already passed on their own.

7. Security aspects: deliberately testing manipulated files

Beyond plain functional checking, it's worth deliberately looking at security-relevant upload scenarios, say a file with a double file extension, a file with deliberately manipulated EXIF metadata, or an overlong file with a deliberately very long filename that could exceed the server's internal path length limits.

These security-oriented test cases shouldn't be treated as a side note, they should be a fixed, recurring part of the test suite for every publicly accessible upload area, since file uploads have historically been among the most common entry points for successful attacks on web applications.

8. Testing multi-file uploads and the order of simultaneously uploaded files

Many Magento product pages allow uploading multiple images for the product gallery in a single operation, which is why a realistic test hands not just a single file but an array of several files to setInputFiles at once and then checks that every single file appears in the gallery in the expected order, instead of limiting itself to the simpler but less realistic single-file case.

An especially revealing test case combines a valid and an invalid file within the same multi-file upload, to check whether the system still successfully processes the valid file and rejects only the invalid one with a clear error message, instead of silently discarding the entire upload operation without any error message in the worst case.

9. Practical Magento context: product images and invoice PDFs

In the Magento admin area, this mainly concerns product image uploads as well as CSV imports of product data, where both file size and actual file content need correct validation, while in the customer account frontend, downloading invoice and shipment PDFs is the most important download test case.

The table below summarizes the test approaches presented for file uploads and downloads.

10. Summary

11. FAQ: File Testing: The Essentials at a Glance