When someone visits your website, your server sends back a bunch of headers along with the page content. Most of these headers are useful. They tell the browser how to handle the page, what kind of content to expect, and how long to cache things. But some headers serve no real purpose for the visitor. They exist because the framework or server you use decided to include them. And they can tell attackers exactly what technology you are running.
Headers like X-Powered-By, X-Runtime, X-Version, and X-AspNet-Version are common examples. They might seem harmless. After all, what is wrong with telling people you use PHP or ASP.NET? The problem is not the framework itself. The problem is that attackers want to know what version you are running so they can look up known vulnerabilities and try to exploit them.
You have probably seen these headers without even realizing it. Open your browser's developer tools. Go to the network tab. Reload a page. Click on the main request. Look at the response headers. You might see something like this:
X-Powered-By: PHP/7.4.33
X-Runtime: 0.023456
X-AspNet-Version: 4.0.30319
X-Version: 1.2.3Each of these headers gives away information. The PHP one tells you the exact version number. The X-Runtime one tells you how long the request took to process, which can give clues about server performance and architecture. The ASP.NET header reveals the framework version. The X-Version header might be your application version or some component version.
None of these headers help the browser render your page. None of them help the user in any way. They are there because the framework developers thought they might be useful for debugging. But on a production site, they are just noise. And for an attacker, they are gold.
Imagine you are an attacker looking for vulnerable websites. You have a list of known vulnerabilities for PHP 7.4.33. You run a scanner that checks millions of sites. When your scanner sees X-Powered-By: PHP/7.4.33, it immediately knows that site might be vulnerable to a specific exploit. It marks that site as a target. Without that header, the attacker would have to try other methods to guess what you are running. Those methods take more time and are less reliable.
The header does not create the vulnerability. The vulnerability exists whether you show the header or not. But the header tells attackers exactly where to look. It saves them time. It makes their job easier. In a world where attackers scan millions of sites automatically, you do not want to be the site that screams "I am running this version" to every bot that passes by.
I have seen this happen in real attacks. A site was running an old version of a content management system. The X-Powered-By header gave away the PHP version. An automated scanner matched that with a known exploit and attacked the site within hours. The site got defaced. If the header had been removed, the scanner might have moved on to the next site. The vulnerability would still be there, but it would be harder to find.
Server headers are similar but come from the web server itself, not the framework. A typical server header looks like this:
Server: nginx/1.18.0This tells you the server software and version. Like framework headers, it gives attackers information they can use. If there is a known exploit for nginx 1.18.0, attackers know to try it on your site. Removing the version number is a good practice. You can keep the server name if you want, but drop the version.
Some administrators remove the server header entirely. That is fine too. The header is not required. Browsers do not need to know what server software you run. It exists for informational purposes only. In production, that information is not something you need to share with the world.
The method for removing headers depends on what server software and framework you use. For Apache, you can use the Header unset directive. Add this to your .htaccess file or virtual host configuration:
Header unset X-Powered-By
Header unset X-RuntimeFor Nginx, you use the proxy_hide_header or add_header directives with an empty value. The exact method depends on whether the header is added by your application or by the server. Often you need to configure both the server and the application.
For PHP-based sites, you can set expose_php = Off in your php.ini file. This stops PHP from sending the X-Powered-By header. Many hosting providers have this turned off by default, but it is worth checking.
For ASP.NET, you can remove the X-AspNet-Version header by adding this to your web.config:
<system.web>
<httpRuntime enableVersionHeader="false" />
</system.web>For Node.js and Express, you can use the helmet middleware. It removes many revealing headers automatically. Or you can set it manually:
app.disable('x-powered-by');For Rails, you can remove the X-Runtime and X-Powered-By headers in your application configuration. The exact settings vary by version, but it is usually a one-line change in config/application.rb or config/environments/production.rb.
Removing the server header is a bit trickier because it is set by the web server itself. For Nginx, you can set server_tokens off. This removes the version number from the server header but still leaves the server name. The header becomes Server: nginx instead of Server: nginx/1.18.0. That is a good compromise. You still show you use nginx, but you hide the specific version.
For Apache, you can use the ServerTokens directive. Set ServerTokens Prod to show only the product name without version. Set ServerTokens ProductOnly for an even shorter header. You can also use mod_headers to completely unset the server header, but that is not always reliable. Some Apache configurations still send it.
If you use a CDN or reverse proxy, the server header might come from that service instead of your origin server. Many CDNs let you control what headers they send. Check their documentation for how to remove or modify server headers.
Removing framework and server headers is a good step, but it is not a complete solution. Attackers have other ways to figure out what technology you are using. They look at URL patterns. They check file extensions. They look for default error pages. They analyze the structure of your HTML and CSS. They use tools that probe your site and guess based on responses.
If you are running an old, vulnerable version of a framework, removing headers does not make the vulnerability go away. It just makes it slightly harder to find. You still need to keep your software updated. Removing headers is defense in depth. It is one layer among many. It stops automated scanners that rely on headers, but it does not stop a determined attacker who is willing to probe deeper.
Think of it like not putting a sign on your front lawn that says "I have expensive electronics inside." The sign does not create the risk. The expensive electronics create the risk. But the sign makes it easier for someone to decide your house is worth targeting. Removing the sign does not make your house secure, but it makes you a less obvious target.
Some people argue that removing these headers is security through obscurity, which is not real security. They say you should focus on fixing vulnerabilities, not hiding them. There is truth to that. Fixing vulnerabilities is always the priority. But hiding information is not useless. It raises the bar for attackers. It forces them to spend more time and effort to find the same information.
In a world where most attacks are automated, raising the bar matters. Automated scanners look for low-hanging fruit. If your site does not offer obvious clues, the scanner moves on. A human attacker might still find the vulnerabilities, but many attacks come from bots, not people. Making the bots work harder is a valid defense.
The real answer is to do both. Fix your vulnerabilities. Keep your software updated. And remove unnecessary headers that give away information. Each layer makes your site harder to attack.
Sometimes developers add their own custom headers that reveal information. Things like X-Developer, X-Build-Number, or X-Environment. These are usually added for internal debugging. They have no place in production. Check your response headers and see if anything looks suspicious. If you find custom headers that reveal internal information, remove them.
I have seen sites that send X-Environment: development in production. That is a clear signal that the site might be misconfigured. Attackers love that. It tells them the site might have debugging features enabled or might be using default credentials. That is a major risk. Check your headers. Make sure nothing like that is leaking.
After you make changes, test them. Use your browser's developer tools. Look at the response headers. Make sure the headers you wanted to remove are gone. If they are still there, figure out why. Maybe you missed a configuration file. Maybe the header is being added by a different layer.
You can also use online tools that check HTTP headers. They will show you exactly what your site sends. Some of these tools also give you security ratings and tell you what headers are missing or should be removed. They are useful for a quick audit.
Remember to test all pages, not just the homepage. Some headers might appear only on certain pages. Error pages are a common place where revealing headers show up. Test a URL that does not exist and see what headers come back. If your error page sends different headers than your normal pages, you need to fix that too.
Header configuration should be part of your standard deployment process. When you set up a new server or deploy a new application, check the headers. Make sure revealing headers are removed. Include this in your configuration management scripts. Treat it like any other security setting. It is easy to forget, but it is also easy to automate.
If you use infrastructure as code, your header configuration should be in your templates. That way every environment gets the same settings. Development environments can keep the headers for debugging, but production should be clean. Having consistency helps avoid mistakes.
I have helped several clients clean up their headers. One client had X-Powered-By headers showing PHP 5.6 on a site that had been upgraded to PHP 7.4. The header was wrong, but it still told attackers they were running an old version. Even though the actual version was newer, the header created a false signal that could attract scanners. We removed the header entirely.
Another client had X-AspNet-Version header showing 4.0 on a site that was no longer using ASP.NET. The header was leftover from an old configuration. It was misleading and unnecessary. Removing it cleaned up the response and stopped giving away irrelevant information.
A third client had a custom X-API-Version header that changed with every release. It was meant for internal debugging but was leaking to public users. We moved that header to an internal endpoint where it was useful but not exposed to the outside world.
Web framework and server headers are small details, but they matter. They are easy to overlook and easy to fix. Taking a few minutes to check your headers and remove unnecessary ones is a quick win for security. It does not solve all your problems, but it makes you a harder target. And in security, being a harder target is often enough to make attackers move on to someone else.
Check your site today. Open developer tools. Look at the response headers. See what you are telling the world. Remove what you do not need. It takes five minutes and makes your site a little safer. That is time well spent.