Forem: Marek Elmayan

How to configure CORS for Next.js

Marek Elmayan — Wed, 29 Jan 2025 13:17:18 +0000

Hey 👋,

I've been working on a new package called next-armored that helps you secure your Next.js application. My first release is out, and I'm excited to share it with you. The first tool I added is a middleware to help you configure CORS for your Next.js server.

If you're only interested in how to use it, and how to set it up, you can directly go check the 👉 tutorial section 👈.

Otherwise, let's start with a quick reminder of what Cross-Origin Resource Sharing (CORS) is and when you need to set it up in your Next.js app.

Drop a star on Github ⭐️

Check on NPM 📦

🔒 I - What is the CORS policy ?

Cross-Origin Resource Sharing a web browser security feature

CORS is a security feature that allows you to control which origins are allowed to access your resources. It is enforced by web browsers through Access-control-allow-* headers.

CORS protects users of your app from malicious sites trying to perform operations (like retrieving personal information or account deletion) on your server without their knowledge. While the request will still reach your server, if it is correctly configured, it will attach CORS security headers based on the request’s origin.

If the request comes from your allowed origins, the browser will allow access to the server’s response.
If the request originates from a disallowed or malicious site, the browser will block access to the response.

For example, in the simplest case of a GET request, an attacker could try to retrieve information. For other methods, such as DELETE, the browser sends a preflight request first. Based on the server's CORS configuration, the browser decides whether to proceed with the request.

For more in-depth information, check this article by a friend of mine or the MDN Documentation.
For insights into CORS vulnerabilities, explore Outpost24’s blog.

❓ What is an origin, and how do you differentiate them?

An origin is defined as a combination of the protocol, host, and port of a resource. For example, the origin of https://example.com/index.html is https://example.com. A change in any of these three components results in a different origin.

⚡️ Subdomains change the host, so https://example.com and https://api.example.com are considered different origins.

🛠️ II - When should you configure CORS for your Next.js application?

We saw that https://example.com and https://api.example.com are different origins. So if your server is at https://api.example.com but your frontend app at https://example.com, you need to configure CORS on your server to allow requests from your frontend.

Why is that? Historically, browsers enforce the Same Origin Policy (SOP), allowing requests only between the same origin for security. This policy’s limitations necessitated the introduction of CORS to enable controlled cross-origin requests, such as inter-operability between different subdomains or public APIs.

Now, what about Next.js ? If you use Next.js 13 or later with the app router (e.g., a folder like ./src/app/api), your frontend (e.g., https://your-domain.com) and API (e.g., https://your-domain.com/api) share the same origin. Here, the SOP suffices, and enabling CORS without a valid reason could introduce vulnerabilities.

So, when should you enable CORS?

If your API is accessed by another frontend (e.g., https://admin.your-domain.com).
If your API is public, allowing access from any origin (ensure the API doesn’t handle sensitive data).

👨🏼‍💻 III - How to configure CORS for Next.js with next-armored

📦 Install the next-armored package

Select your favorite package manager (e.g. pnpm) and install the next-armored package by running:

pnpm add next-armored

🥇 Use the CORS middleware as your first middleware

Create or update your ./src/middleware.ts:

import { NextRequest } from "next/server";
import { createCorsMiddleware } from "next-armored/cors";

const corsMiddleware = createCorsMiddleware({
  origins: ["https://example.com", "http://localhost:5173"],
});

export function middleware(request: NextRequest) {
  return corsMiddleware(request);
}

export const config = {
  matcher: ["/api/:path*"],
};

In Next.js, the middleware is executed before every request matching the matcher pattern inside the config object.
For this example, I will suppose that you just created the middleware file. So you just need to match all your api routes.
If you are using the app router, you can match all your api routes by using the '/api/:path*' pattern.
Then import the createCorsMiddleware function from next-armored/cors and pass your configuration object to it. This will allow you to build the cors middleware with the origins you want to allow and pass it to the middleware function.

🎼 Compose your CORS middleware with other middleware

If you already have middleware, compose them as follows:

import { NextRequest, NextResponse } from "next/server";
import { createCorsMiddleware } from "next-armored/cors";

const corsMiddleware = createCorsMiddleware({
  origins: ["https://example.com", "http://localhost:5173"],
});

const otherMiddleware = (request: NextRequest) => {
  console.log("otherMiddleware");
  return NextResponse.next();
};

export function middleware(request: NextRequest) {
  const response = otherMiddleware(request);
  const isApi = request.nextUrl.pathname.startsWith("/api");
  if (isApi) {
    return corsMiddleware(request, response);
  }
  return response;
}

export const config = {
  matcher: ["/api/:path*", "/home/:path*"],
};

If your matcher didn't previously include the api routes, you will have to add it to the matcher.
Then you can call the other middleware first and get the response.
Since the cors middleware should be applied only to the api routes, you have to check if the request is an api request and then apply the cors middleware only in that case. This can be done easily by checking the pathname of the request with request.nextUrl.pathname.startsWith('/api').

Finally, pass the response to the cors middleware as the 2nd argument. In this case, the cors middleware will attach the headers to the existing response instead of returning a new response.

Alternatively, use a utility to chain middleware. Here is a snippet of how you can do it but it shall be adapted to the need of each.

export type CustomMiddleware = (
  request: NextRequest,
  event: NextFetchEvent,
  response: NextResponse
) => NextMiddlewareResult;

type MiddlewareFactory = (next: CustomMiddleware) => CustomMiddleware;

export const chainMiddlewares = (
  functions: MiddlewareFactory[],
  index = 0
): CustomMiddleware => {
  const current = functions[index];

  if (current) {
    const next = chainMiddlewares(functions, index + 1);

    return current(next);
  }

  return (
    _request: NextRequest,
    _event: NextFetchEvent,
    response: NextResponse
  ) => response;
};

export const middleware = chainMiddleware([
  middleware1,
  middleware2,
  corsMiddleware,
]);

⚙️ Full CORS middleware configuration

const corsMiddleware = createCorsMiddleware({
  origins: ["https://example.com", "http://localhost:5173"],
  methods: ["GET", "POST"],
  headers: ["Content-Type"],
  maxAge: 60 * 60 * 24,
  optionsSuccessStatus: 204,
  allowCredentials: true,
  exposedHeaders: ["Content-Type"],
  preflightContinue: false,
});

You have to at least specify the origins option because keeping * by default is not recommended as it can be a security risk. If you are building a public api, you can allow all origins by passing origins: ['*'] but you should be aware of the security implications.

You can define other options as well:

origins - array of origins that are allowed to access the resource. The only one to be required.
methods - array of methods that are allowed to access the resource. Default value to ["GET", "POST", "PUT", "DELETE", "PATCH", "OPTIONS"].
headers - array of headers that are allowed to access the resource. Default value to ["Content-Type", "Authorization"].
maxAge - number of seconds that the results of a preflight request can be cached. Default value to 60 * 60 * 24 (1 day).
optionsSuccessStatus - status code to send for successful OPTIONS requests. Default value to 204.
allowCredentials - boolean value to indicate if credentials are allowed to be sent with the request. Default value to true.
exposedHeaders - array of headers that are exposed to the client. Default value to [].
preflightContinue - boolean value to indicate if it should pass the CORS preflight response to the next handler. Default value to false.

🚫 Enable/disable CORS for specific paths

Enable CORS for specific paths:

const corsMiddleware = createCorsMiddleware(
  { origins: ["https://example.com", "http://localhost:5173"] },
  {
    includes: [{ startsWith: "/api/v2", additionalIncludes: ["example"] }],
  }
);

This will enable CORS for all paths that start with /api/v2 and at the same time include example in the pathname.
api/v2/product/example will have CORS enabled, but api/v1/product/example/test will not.

Disable CORS for specific paths:

const corsMiddleware = createCorsMiddleware(
  { origins: ["https://example.com", "http://localhost:5173"] },
  {
    excludes: [{ startsWith: "/api/restricted" }],
  }
);

In this case, all the routes starting with /api/restricted will not enforce CORS but the SOP (Same-Origin Policy) as the default behavior suggests.

🔮 IV - Why use `next-armored`?

🚀 Easy to use: Create the middleware with few lines.
🔧 Flexible: Customize middleware configurations to fit your needs.
🛡️ Secure: Default configurations are based on best practices and security standards.
✅ Type-safe: Middleware is fully typed and compatible with Next.js and TypeScript. Also it's tree-shakable.
🌐 Open source: Audit, report issues, and contribute.

🔎 V - Next steps for `next-armored`

I started with a cors middleware for Next.js but my goal is to create a bunch of utils to help you secure your Next.js application. So I definitely plan to add more utils and more middleware to this package.
The next one will probably be a middleware to handle Content Security Policy (CSP) headers. But if you have any suggestion, or specific needs, please let me know. 😊

Drop a star on Github ⭐️

Check on NPM 📦

Mastering File Upload Security: DoS and Antivirus

Marek Elmayan — Wed, 20 Mar 2024 13:45:00 +0000

TL;DR:

Mitigate Denial of Service (DoS) threats by imposing restrictions on both the size of files and the quantity of uploads permitted on your server.
Implement antivirus scanning for files that users download, ensuring protection against malware infections.

File Upload vulnerabilities and security challenges

Incorporating a file upload feature into your website introduces a spectrum of vulnerabilities that can compromise not only your servers but also the integrity and safety of your users' data.

This article aims to shed light on the critical security challenges associated with file uploads and offers a roadmap to safeguard your digital infrastructure against malicious attacks. We'll explore strategies to prevent attackers from exploiting file upload functionalities to overload and destabilize your servers. Additionally, considering the risks posed when users download files uploaded by others, we emphasize the importance of integrating robust antivirus scanning processes.

⚡️ Denial of Service (DoS) attacks

A Denial of Service (DoS) attack is a malicious attempt to disrupt the normal functioning of a network, service, website, or computer system by overwhelming it with a flood of traffic or requests. The primary objective of a DoS attack is to make a target system or network unavailable to its users, thereby denying access to legitimate users. In our case, uploading specific files can result in service disruptions for unsafe server configurations.

Considering a file upload stream what are the possibilities to block the traffic?

Voluminous File Upload: This vulnerability occurs when an attacker uploads an extremely large file, often much larger than what the system is designed to handle. Such a file can consume all available server resources, such as disk space, memory, and processing power, causing the system to slow down or even crash.

Multiple Small File Upload: In this scenario, an attacker uploads a large number of relatively small files. While individual files may not be large, the cumulative impact can lead to resource depletion or storage space exhaustion.

🛡️ How to prevent file upload DoS attacks from happening?

To deal with these vulnerabilities, it's essential to implement proper security measures in the backend part of your file upload feature. It’s relatively easy and straightforward to do.

Set appropriate file size limits to prevent the upload of excessively large files that could overload your system.
Set a limit to the number of simultaneous files that can be uploaded at the same time.

Here is an elementary Typescript implementation example:

const maxFiles = 6;
const maxFileSize = 50 * 1024 * 1024; // 50 MB limit

const uploadedFiles: File[] = req.body.files;
// Assuming 'files' is an array of File objects in the request body

// Check file size and number of files
if (uploadedFiles.length > maxFiles) {
  return res.status(400).json({ error: "Too many files uploaded." });
}

for (const file of uploadedFiles) {
  if (file.size > maxFileSize) {
    return res.status(400).json({ error: "File size exceeds the limit." });
  }
  // Handle the file, e.g., save it to the server
}

return res.status(200).json({ message: "Files uploaded successfully!" });

More general tips to prevent any type of DoS attacks are:

Implementing rate limiting for file uploads to prevent the rapid uploading of numerous small files. This helps control the flow of incoming data.
IP blocking → blocking traffic from known or suspected malicious sources to prevent DoS traffic from reaching its target. You can find lists of abusive IPs, for instance on abuseipdb.com
Using a Content Delivery Networks (CDNs) such as Cloudflare, can help absorb large amounts of traffic and mitigate the impact of DoS attacks.

Additional benefits of DoS protection measure: 💰 & 🌱

Using smaller and fewer files can bring also other benefits to you and the environment.

With less quantity to store on your server, you will have better performances and less to pay at the end of the month.
Moreover, less storage usage will reduce the environmental impact of manufacturing, operating, and cooling data centers.
Sending voluminous files is also costly so even though front-end file size validation isn’t enough for security measure it can help to reduce the environmental impact of the uses.

💣 What is a Zip Bomb? A type of DoS attack

A Zip Bomb, also known as a Zip of Death or decompression bomb, is a malicious archive file designed to crash or render useless the program or system reading it. It's a type of DoS attack. The concept behind a Zip Bomb is to exploit the file compression algorithm's ability to highly compress a large amount of data. A Zip Bomb file appears small and innocuous but contains an enormous amount of data when decompressed.

When a targeted system tries to decompress such a file, it can exhaust system resources due to the disproportionally large size of the decompressed data compared to the compressed file. For example, a Zip Bomb could be a file that is only a few kilobytes in size but expands to several gigabytes or even terabytes when decompressed. This can lead to system crashes, slowdowns, or can render the system inoperable, thus achieving the attacker's goal of denying service to legitimate users.

Zip Bombs are not only limited to Zip files; they can be created in any file format that supports compression, such as RAR or 7z. Accepting an archive file is always a delicate matter, and decompressing it on your server even more so. The defense against Zip Bombs involves careful scanning and validation of input files, limiting the maximum size of decompressed data, and using updated antivirus and anti-malware programs capable of detecting such threats.

🕵️‍♂️ Antivirus scanning for user protection

The purpose of uploading files is very often to share them with other people thus another user is supposed to download the file afterwards. These users can inadvertently become targets of malicious activity when using file upload features on web applications. In many cases, attackers may attempt to exploit the trust of users by uploading files that appear harmless but, in reality, contain malware or other malicious content. This can include infected documents, executables, or scripts. When these files are downloaded and executed on a user's system, it can lead to compromised security and potential data breaches.

If the uploaded files are retrievable, to safeguard both your platform and mainly your users, it is crucial to run an up-to-date virus scanner. Virus scanners are very adept at spotting malicious files masquerading as a different file type, invisible to most unaware users. This proactive measure can automatically check each uploaded file for potential threats, helping ensure that users are not unwittingly exposed to malicious content.

Running an antivirus can also help you secure your server, because it can detect potentially malicious files that succeeded in bypassing all your previous security checks.

Before really uploading a file you can isolate it and run an antivirus to identify potential threats, then only finally uploading it. This way all potential threats are being neutralised before having access to sensitive data.

⭐️ Recommendations to go beyond simple antivirus scanning

For maximal safety, you can implement multi-scanning. For each file run multiple anti-malware engines, which can be parallelised, in order to get the highest detection rate and the shortest window of exposure to malware outbreaks. Here are some reasons:

Malware can bypass a single antivirus engine.
Different anti-virus vendors have different response times to outbreaks due to their location and focused markets.
False positives in virus detection are a common side-effect of any malware scanning solution.

Lastly, if you have to choose between an Online and an Offline antivirus, you should probably prefer an online solution.

If you use offline antivirus software, you have to download and install it in your system. While online virus scanner does not require any storage space.
Real-time Protection & Regular Updates: Online antivirus software constantly updates its virus definitions and scans your system in real-time, providing immediate protection against the latest threats. Online antivirus solutions automatically receive updates and patches to keep up with the evolving threat landscape.
Cloud-Based: Online antivirus relies on cloud servers to analyse files and detect malware. This reduces the strain on your computer's resources and can be more efficient since the processing part is usually done on high-speed cloud-based servers.
Enhanced Detection: Online antivirus solutions often use behavioural analysis and machine learning algorithms to identify previously unseen malware, improving their ability to detect new threats.
Less Control & Privacy: Data sent to external servers and no customisation according to personal preferences are the main drawbacks that would make you prefer an offline solution.

My recommendation would be to use ClamAV an open source antivirus engine. It is a versatile tool designed to detect multiple types of threats from numerous file formats and other use cases (cross-platform, integration such as mail server). Finally, it is updated on a daily basis, ensuring protection against the latest known threats. This rapid update cycle is crucial for an antivirus tool to be effective.

Setting up AWS antivirus scanning for files in S3 Buckets

You can find a guide on the AWS blog, detailing how to integrate Amazon S3 Malware Scanning into your web App. Amazon Simple Storage Service (Amazon S3) is a highly scalable object storage service that allows file storage. Currently, when a file is uploaded to an S3 Bucket, two scanning engines are available: Sophos and ClamAV, to detect malicious ones. Additionally, both engines can be used together for an even higher safety.

Asynchronous antivirus scanning to enhance performance and UX

Running an extensive antivirus engine can be quite time-consuming thus implementing asynchronous antivirus scanning can significantly enhance both performance and user experience in systems that require real-time or near-real-time processing. This approach involves decoupling the scanning process from the main application flow, allowing the application to continue executing without waiting for the scan to complete.

When a user uploads a file, the server immediately acknowledges receipt and begins the upload process, providing a responsive experience.
The file is being processed in the background, scanned and uploaded if successful or either deleted or quarantined if not.
Send a status update on the upload process to the user, such as through email notifications, dashboard updates, or real-time alerts using web sockets.

🏎️ Race conditions applied to file upload

Race conditions in cybersecurity refer to a scenario where the outcome of a process is unexpectedly altered due to the timing of events not happening as planned. This occurs in a concurrent environment where multiple processes or threads execute in overlapping timeframes, leading to conflicts in accessing or modifying shared resources. The security risk arises when an attacker can manipulate the timing of actions to gain unauthorized access or privileges, modify data, or exploit system functionality in unintended ways.

In the context of file upload vulnerabilities, race conditions can be particularly concerning. There are multiple scenarios where the file security checks could be bypassed. Here is one example:

Imagine a web application that allows users to upload files. The application checks the file for security purposes (e.g., ensuring it's not a malicious executable) before moving it to a permanent storage location. A race condition vulnerability could occur if an attacker manages to manipulate the timing of the upload process.

Initial Upload: The attacker begins by uploading a benign file that passes the application's security checks.
Timing Manipulation: Right after the initial check but before the file is moved to its permanent location, the attacker quickly replaces the benign file with a malicious one, exploiting the time gap in the process.
Execution of Malicious File: The application, believing the file to be safe, moves it to permanent storage, from where the attacker can trigger the execution or processing of the malicious file.

This exploitation leverages the race condition to bypass security checks, allowing the upload and execution of potentially harmful files.

You can try yourself exploiting a file upload race condition vulnerability, of a different kind, on this Portswigger’s Lab.

Conclusion:

I hope this article has provided you with a comprehensive understanding of the security challenges associated with file uploads and the strategies to mitigate these risks. By implementing the recommended security measures, you can ensure that your file upload feature is robust, resilient, and secure, protecting your servers and users from potential threats.

If you'd like to find out more about file type validation, take a look at the first article in this series: Mastering File Upload Security: Understanding File Types.

Mastering File Upload Security: Understanding File Types

Marek Elmayan — Wed, 06 Dec 2023 14:30:52 +0000

In today's digital landscape, file exchange has become an integral part of our online activities, from sharing work documents to uploading pictures on social media. However, this convenience comes with inherent risks. File upload functions, seemingly innocuous, can serve as potent vectors for high-severity attacks, potentially jeopardizing your data and user security. Whether you're a seasoned developer or just embarking on your coding journey, ensuring the security of your file upload features is paramount.

To address this concern, it's crucial to understand the concept of file types, including file extensions and MIME types. These are fundamental to ensure the proper handling and validation of uploaded files and thus prevent some malicious files from being uploaded to your application.

How to determine the type of a file? Introducing extension & MIME type

File Extensions

File extensions are suffixes added to a file's name, typically separated from the base filename by a dot (e.g., .jpg, .pdf, .txt). They serve as a way to identify the file format, which can be important for both the operating system and the user.

File extensions are a common way for users to recognize the type of a file. For example, .jpg or .jpeg extensions are associated with image files, while .pdf extensions denote documents. However, it's important to note that file extensions can be manipulated or spoofed by malicious users, making them an unreliable method for file type verification.

Developers should not solely rely on file extensions when validating the types of uploaded files in a web application. An attacker could easily rename a malicious file with a benign extension, exploiting this vulnerability.

MIME Types

MIME (Multipurpose Internet Mail Extensions) types, on the other hand, provide a more reliable way to identify the content type of a file. MIME types are associated with the actual content of the file rather than its name.

A MIME type is typically expressed as a two-part identifier, separated by a slash (/). The first part specifies the general category of the file, such as text for plain text documents or image for image files. The second part provides more specific information about the file's format, such as html for HTML web pages or jpeg for JPEG image files. Together, these two parts form a complete MIME type, like text/html for HTML documents or image/jpeg for JPEG images.

These MIME types are standardized, and web servers use them to indicate the content type of a file in HTTP headers when serving files over the web. You can check the Common MIME types 👀

When dealing with file uploads, you can extract the MIME type from the file's metadata, allowing you to verify its content regardless of the file's name or extension. This helps prevent attackers from disguising malicious content by simply changing the file extension.

Here is a quick command line example showing that modifying the extension of a file doesn’t change its mime type and doesn’t prevent it from being executed.

cat hello.php
# output: <?php echo "Hello World!"; ?>

file --mime-type hello.php
# output: hello.php: text/x-php

php hello.php
# output: Hello world!

cp hello.php hello.png

file --mime-type hello.png
# output: main.png: text/x-php

php hello.png
# output: Hello world!

🪄 Magic Numbers hidden in the File Metadata

File metadata refers to the hidden information or attributes associated with a file. Basically, metadata are data about the data, it provides essential context about the file, such as its creation date, author, size, and information about its content. From our security point of view, it’s the last information that interests us. By examining metadata, we can gain insights into the nature of uploaded files and deduce their MIME type ✨.

Magic numbers, also known as magic bytes or file signatures, are special values or sequences of bytes located at the beginning of a file, in the metadata, that help identify the file's format or type. They serve as a way for software to quickly determine the nature of a file without having to rely solely on its file extension. Magic numbers are commonly used to ensure that the correct software or application is used to open and interpret the file.

Here are some common examples:

File type	Extension	Hex digits
PDF format	.pdf	25 50 44 46
PNG format	.png	89 50 4e 47
GIF format	.gif	47 49 46 38

You can check a more extensive list of file signatures.

The command hexdump -C is used in Unix-like operating systems to display the contents of a file in hexadecimal format along with printable ASCII characters. Here is a way to check that your PDF is legitimate by verifying its magic number.

🛠️ Unreliable tools to help with quick type validation

What is the Content-Type header ?

The Content-Type header is an HTTP header used to indicate the media type or MIME type of the data that is being sent in the HTTP response. This header is crucial for web servers and clients to understand how to process the content they receive. For example, when a web server sends an HTML web page to a browser, it includes the Content-Type header with a value of "text/html" to inform the browser that it should interpret and display the content as an HTML document.

However, the Content-Type header should not be relied upon for robust file type validation, especially for security-critical applications.

The Content-Type for uploaded files is provided by the client in the HTTP request, thus it can be manipulated by malicious users. Hence it cannot be trusted, as it is trivial to spoof. Although it should not be relied upon for security, it can provide a quick check to prevent users from unintentionally uploading files with the incorrect type.

`<input type='file'/>` HTML component

To let users upload files to your web application, you can use the HTML <input type="file"> element. This element creates a file picker dialog that allows users to select one or more files from their local device. The selected files can then be uploaded to the server using a form submission or an AJAX request.

<form action="/upload" method="post" enctype="multipart/form-data">
  <input type="file" name="file" />
  <input type="submit" value="Upload" />
</form>

You can even specify the types of files that users can select by using the accept attribute. This attribute accepts a comma-separated list of MIME types or file extensions. For example, to only allow users to select image files, you can use the following code:

<input type="file" name="file" accept="image/*" />

Nevertheless, it's important to note that the accept attribute is only a hint to the browser and does not provide any security. It's trivial for malicious users to bypass this restriction by simply modifying the file picker dialog or sending a request directly to the server. According to the documentation, only the extension is used to determine the type of the file. Therefore, it is not a reliable way to validate the type of uploaded files but it can be used to prevent users from unintentionally uploading files with the incorrect type.

🔒 Secure your app and your file upload feature

Ensure the usage of business-critical extensions only, without allowing any type of non-required extensions.

🧬 Using Both Extensions and MIME Types:

To achieve robust security, it's advisable to combine both file extensions and MIME types when validating uploaded files. By cross-referencing the file extension with the extracted MIME type, you can add an extra layer of protection to your application. This ensures that the file's content matches its declared extension.

✅ Whitelist relevant types

Based on your web application's needs, ensure the least harmful and the lowest risk file types to be used. By limiting the list of allowed file types, you can already avoid executables, scripts, and other potentially malicious content from being uploaded to your application.

For instance, allow only common image types for a picture sharing feature, such as png, jpeg, svg.

⚠️ Having protection against file type doesn't mean that it is robust. Some flaws likely exist in the mechanisms implemented to validate the file type. One example among many, is the file extension can be spoofed by using a double extension such as image.png.php or image.png%00.php (null byte injection).

→ The use of a deny list is inherently flawed as it's difficult to explicitly block every possible file extension that could be used to execute code. (It can be bypassed by using lesser known, alternative file extensions that may still be executable, such as .php5, .shtml, .docm, ... )

→ Ensure that the validation occurs after decoding the file name and that a proper filter is set in place in order to avoid certain known bypasses.

For more information and practical knowledge, check the following Portswigger topic.

🥷 Exploiting file type vulnerabilities with Polyglot Files 🎭

Tempering directly the magic number of a file isn’t a big risk since it will make it unreadable to programs thus preventing malicious code execution. Nevertheless, there is a special category of files, called Polyglot files, that are used to exploit vulnerabilities in file validation.

Inspired by the analogy to multilingualism, they are files that are deliberately crafted to be valid and functional in multiple file formats simultaneously.

For instance, a PDF-ZIP polyglot can be opened as a valid PDF document and also at the same time decompressed as a valid ZIP archive. Hence if you allow the upload of PDF files then you can bypass the type restriction and upload a ZIP archive.

Here is a polyglot program that can be interpreted as a C++ or as a Python program depending on the compiler used. The common technique used is to make use of languages that use different characters for comments.

#if 0
print('Hello world')
#endif
#if 0
""" "
#endif
#include <iostream>
int main() {
    std::cout << "Hello world" << std::endl;
}
#if 0
" """
#endif

For a PDF-ZIP file, it is more complicated since you need to understand the structure of the file and how to craft it to be valid in both formats by manipulating bytes. Many different methods can be used to create polyglot files and it is not limited to 2 types for a single file. I will not go into details about the process of creating polyglot files but here are some resources to get started on this fascinating topic.
Here is a list of polyglot files you can manipulate and test. Otherwise, you can use Mitra to create your own polyglot files.

How to prevent polyglot files from being uploaded to your application?

Set up a very strict validation process that will reject any file that shows any sign of anomaly.
Sanitize the file content.
Verify the file through an antivirus software.

All the above methods are complex, not light to implement, and not always necessary depending on the context of your application. However, it is important to be aware of the existence of polyglot files and the risks they represent.
The next step is to configure your server safely, thus preventing the execution of malicious code.

🚀 Stay tuned for the next steps

I hope you now understand more about how file types work. File type validation is a complex process, and no single method is infallible or sufficient. Using a combination of methods to protect against file upload attacks is recommended.

Stay tuned if you are interested in file upload vulnerabilities such as remote code execution (RCE) or Denial of Service (DoS) attacks. I’ll help you get a gist of it and guide you to safely configure your server and protect your user from downloading malicious files.