Let's Start with a Simple Question

Imagine you are a thief. You want to rob a house. You walk down the street looking for targets.

One house has a sign on the lawn that says: "This house uses a Smith & Wesson Model 6906 alarm system. Firmware version 2.3.1. Installed January 2022."

How helpful is that?

Very helpful. Now you know exactly which alarm system to look up. You search online for vulnerabilities in that specific model. You find a known bypass. You break in.

That is an Information Leak.

When your API sends headers to anyone who asks, those headers might announce your technology stack. Your server type. Your version number. Your framework.

Attackers read these headers. They look up known vulnerabilities for your specific technology. They attack you using those vulnerabilities.

Your customers never need to know what server you use. But your API tells them anyway.

What is Information Leak? The Simple Definition

Information Leak means your API is advertising your technology stack to anyone who asks.

Every time a browser or tool makes a request to your API, your server sends back response headers. These headers are metadata about the response. They tell the client how to handle the data.

But some headers also tell the client what technology you are using.

A header might say Server: nginx/1.18.0. Now the attacker knows you are using Nginx version 1.18.0.

A header might say X-Powered-By: Express. Now the attacker knows you are using Express.js.

A header might say X-AspNet-Version: 4.0.30319. Now the attacker knows you are using ASP.NET.

None of this information helps your regular users. They do not care what server you use. They just want your app to work.

But this information helps attackers immensely. They look up known vulnerabilities for your specific server and version. They find exploits. They attack.

A Story About Two Headers

Let me tell you a story about how an attacker uses information leaks.

Eve is an attacker. She wants to break into a company's API. She does not know anything about their technology stack. She starts with a simple request.

She opens her browser's developer tools. She looks at the Network tab. She finds an API call. She looks at the response headers.

She sees: Server: Uvicorn

Eve has never heard of Uvicorn. She opens a new tab. She searches Google for "Uvicorn".

She learns that Uvicorn is an open source Python web server. Now she knows the API is written in Python.

She searches again: "Uvicorn CVE". CVE stands for Common Vulnerabilities and Exposures. These are publicly known security holes.

She finds several CVEs for Uvicorn. She reads about each one. She finds one that allows remote code execution.

She tries the exploit on the target API. It works. She now has full access to their servers.

All because the API sent a Server: Uvicorn header.

Let's make it easier

Imagine you go to a restaurant. You sit down. You look at the menu.

The menu lists the dishes. That is normal.

But imagine the menu also lists: "Our kitchen uses a Samsung 48-inch gas range, model number GR48–2021, purchased March 2021 from Restaurant Supply Co. The oven is calibrated to 350 degrees. The refrigerator is a True Manufacturing T-49."

You do not need this information. You just want to eat.

But a competitor restaurant owner reading this menu learns exactly what equipment you use. They look up known problems with that equipment. They find that the oven has a faulty thermostat. They call the health inspector.

That is Information Leak. You gave away information that helps people attack you.

Where Do These Leaks Come From?

Most web servers and frameworks send these headers by default. They are trying to be helpful. They want clients to know what server they are talking to.

But being helpful to attackers is dangerous.

Here are common headers that leak information.

Server tells the client what web server software you are running. Examples: nginx, Apache, IIS, Uvicorn, Gunicorn.

X-Powered-By tells the client what framework you are using. Examples: Express, PHP, ASP.NET.

X-AspNet-Version tells the client what version of ASP.NET you are using.

X-Drupal-Cache tells the client you are using Drupal.

X-Generator tells the client what software generated the page.

Via tells the client what proxy servers or caching servers are in between.

Some servers even send version numbers. Server: nginx/1.18.0 is much worse than Server: nginx. The version number helps attackers find exploits for that specific version.

How Attackers Use Information Leaks

Attackers follow a simple process.

Step 1: They make a request to your API. Any request. They look at the response headers.

Step 2: They find headers that reveal your technology stack. Server type, framework, version numbers.

Step 3: They search for known vulnerabilities for that technology. They use public databases like CVE.

Step 4: They look up exploits for those vulnerabilities. Many exploits are publicly available.

Step 5: They try the exploits against your API. If you have not patched the vulnerability, they get in.

This process takes minutes. Attackers have automated tools that do this for thousands of APIs per hour.

Obscure technologies are actually more dangerous. If you use Nginx, millions of people use Nginx. Vulnerabilities are found quickly and patched quickly.

If you use an obscure Python server like Uvicorn, fewer people use it. Fewer people have audited its security. Unknown vulnerabilities might exist. And the attacker knows exactly what to research.

Real Examples of Information Leaks

Let me show you real headers from real websites.

One website sends: Server: nginx/1.18.0

An attacker searches "nginx 1.18.0 vulnerabilities". They find CVE-2021–23017, a request smuggling vulnerability. They try it.

Another website sends: X-Powered-By: PHP/7.4.33

An attacker searches "PHP 7.4.33 vulnerabilities". They find CVE-2022–31626, a buffer overflow vulnerability. They try it.

Another website sends: Server: Microsoft-IIS/10.0

An attacker searches "IIS 10.0 vulnerabilities". They find CVE-2022–21907, a remote code execution vulnerability. They try it.

In each case, the attacker learned everything they needed from a single header. They did not need to guess. The API told them.

The Nginx Example

Nginx is one of the most popular web servers. It has many known vulnerabilities.

If your API sends Server: nginx, an attacker knows to try Nginx exploits.

If your API sends Server: nginx/1.18.0, an attacker knows exactly which exploits to try. They do not need to guess. They look up vulnerabilities for version 1.18.0 specifically.

The difference between nginx and nginx/1.18.0 is the difference between a general warning and a detailed blueprint.

Your customers do not need either.

The Uvicorn Example

In the APIsec University video, Anthony Aragues found an API that sent Server: Uvicorn.

He had never heard of Uvicorn. So he searched for it. He learned it was an open source Python web server.

Then he searched for Uvicorn CVEs. He found known vulnerabilities. He could try to exploit them.

All from one header.

This is the power of information leaks. Attackers do not need to know everything. They just need one clue. They chase that clue down the rabbit hole until they find a way in.

How to Fix Information Leaks

The good news is that fixing information leaks is easy. Most web servers and frameworks have simple ways to remove these headers.

For Nginx, add this line to your configuration file:

server_tokens off;

This removes the version number. The header becomes Server: nginx instead of Server: nginx/1.18.0. Even better, you can remove the header completely.

For Apache, add this to your configuration:

ServerSignature Off ServerTokens Prod

For Express.js (Node.js), use the Helmet package:

const helmet = require('helmet'); app.use(helmet());

Helmet removes many leaking headers automatically. It also adds other security headers.

For IIS, you need to edit the registry or use URLScan. Search for "IIS remove server header" for specific instructions.

For any server, search Google for "remove server header [your server name]". The solution is usually simple.

The Quick Checklist for Information Leaks

Here is how to check your own APIs for information leaks.

Step 1: Open your browser's developer tools. Go to the Network tab.

Step 2: Make a request to your API. Any request.

Step 3: Look at the response headers. Scroll through the list.

Step 4: Look for headers like Server, X-Powered-By, X-AspNet-Version, Via, and any header that contains technology names or version numbers.

Step 5: If you see any of these, you have an information leak.

Step 6: Remove them using your server or framework configuration.

Step 7: Test again to make sure the headers are gone.

Do not forget to check cached responses. Sometimes cached responses come from a caching server and have different headers. Make sure you are hitting your actual API server, not a cache.

You can use tools like Postman or curl to make direct requests to your API. This bypasses caches and shows you exactly what your server sends.

What You Need to Remember

Here are the big ideas from this lesson.

Information Leak happens when your API sends headers that reveal your technology stack. Server type, framework, version numbers.

Your customers do not need this information. Only attackers benefit from it.

Attackers use information leaks to look up known vulnerabilities for your specific technology. They find exploits and attack you.

Most web servers send these headers by default. You must turn them off.

Fixing information leaks is easy. One line of configuration or one package like Helmet.

After you fix it, test again. Make sure the headers are gone.

The best header is no header. Remove everything that does not help your users.

The 3-Question Test for Information Leaks

Ask yourself these three questions.

Question 1: Does my API send a Server header? If yes, you are leaking information.

Question 2: Does my API send an X-Powered-By header? If yes, you are leaking information.

Question 3: Do any of my headers contain version numbers? If yes, you are leaking dangerous information.

One Final Thought

A good security person thinks like an attacker.

Open your browser's developer tools. Look at the response headers from your own API. What do you see?

Do you see Server: nginx? Do you see X-Powered-By: Express? Do you see version numbers?

Now imagine you are an attacker. What would you do with that information?

You would search for vulnerabilities. You would find exploits. You would try them.

Remove those headers. Give attackers nothing.

Your Turn

Open your browser's developer tools right now. Go to any website you use. Look at the Network tab. Click on a request. Look at the response headers.

Do you see a Server header? Do you see X-Powered-By?

Now check your own API. What does it send?

These questions are why information leaks are such a common and easy-to-fix vulnerability.