
Click to WordPress Web Hositng from $7.47 per month
When an Apache web server generates an error page, it may display information about the server at the bottom of the page.
This information is known as the server signature.
Depending on the server configuration, it may include the Apache version, server hostname, or other details about the server environment.
Although this information can be useful for troubleshooting, website owners may prefer not to display unnecessary server details to visitors.
Fortunately, Apache provides a simple directive called ServerSignature that can be configured through an .htaccess file.
We will explain what an Apache server signature is, how to disable it using .htaccess, how to verify the change, and how to reduce additional server information exposure.
What Is an Apache Server Signature?
An Apache server signature is a footer that Apache can automatically append to certain server-generated pages, particularly error pages such as 403 Forbidden and 404 Not Found.
For example, when server signatures are enabled, an Apache-generated error page might display information similar to the following:
Apache/2.4.x (Unix) Server at example.com Port 80
This information may reveal the web server software, version, hostname, or port number, depending on the Apache configuration.
The server signature is different from the Server HTTP response header.
The signature appears in the body of certain server-generated documents, while the Server header is transmitted as part of the HTTP response.
Disabling the server signature does not automatically remove the Server HTTP header.
Why Should You Disable the Server Signature?
Disabling the Apache server signature is a simple configuration measure that can reduce unnecessary information disclosure.
When detailed server information is publicly displayed, automated scanners and attackers may use it to identify the software environment and look for potentially relevant vulnerabilities.
However, hiding server information does not eliminate those vulnerabilities or prevent attackers from identifying the software through other methods.
The primary advantages of disabling server signatures include reducing unnecessary information disclosure, keeping server-generated error pages cleaner, and avoiding the display of technical details that ordinary visitors do not need.
It is important to remember that disabling the server signature is not a replacement for security updates, proper permissions, firewall rules, or secure server configuration.
Step 1: Locate Your .htaccess File
The .htaccess file is a configuration file used by Apache to apply certain settings to a directory and its subdirectories.
If your website uses Apache and the hosting provider allows the necessary overrides, you can disable the server signature without modifying the main Apache configuration.
First, log in to your web hosting control panel or connect to your hosting account using SFTP or SSH.
If you use cPanel, open File Manager and navigate to the document root of your website.
For many primary-domain installations, this directory is named public_html.
Look for a file named .htaccess. Because its filename begins with a dot, it may be hidden by default.
In cPanel File Manager, enable the option to display hidden files if necessary.
If the file already exists, download a backup before making changes.
If the file does not exist, you can create a new plain-text file named .htaccess, provided your hosting environment supports Apache .htaccess configuration.
Be careful not to delete existing WordPress rewrite rules or other directives already stored in the file.
Step 2: Disable the Apache Server Signature
Open your website’s .htaccess file and add the following directive:
ServerSignature Off
Save the file after adding the directive.
That is the only Apache directive required to disable server signatures in the applicable directory context.
The ServerSignature directive controls whether Apache adds its identification footer to server-generated documents.
When ServerSignature is set to Off, Apache suppresses that footer.
When it is set to On, Apache may include the server identification information on supported server-generated pages.
Apache HTTP Server 2.4 uses ServerSignature Off as its default setting.
Therefore, adding this directive may not produce any visible change if the server signature is already disabled.
The directive is supported in .htaccess files when the Apache configuration permits it through the appropriate AllowOverride settings.
Step 3: Save the File and Test Your Website
After saving the modified .htaccess file, open your website in a browser and confirm that it loads normally.
Next, request a URL that does not exist on your website, such as:
https://example.com/nonexistent-test-page
Replace example.com with your actual domain name.
If Apache generates the 404 error page directly, check whether server identification information appears at the bottom.
When ServerSignature Off is active, Apache should not append its server signature footer to that page.
However, many websites use custom error pages.
WordPress, for example, commonly generates its own 404 pages through the active theme.
In such cases, the absence of a server signature does not necessarily prove that the Apache setting has changed.
You may need to test an Apache-generated error response or ask your hosting provider to verify the effective configuration.
If your website returns a 500 Internal Server Error immediately after modifying .htaccess, restore the original file and check whether the hosting environment allows the ServerSignature directive.
Step 4: Understand the Difference Between ServerSignature and ServerTokens
Apache provides another directive called ServerTokens. Although the two directives are related, they perform different functions.
ServerSignature controls the identification footer on certain server-generated pages.
ServerTokens controls how much server identification information Apache includes in its Server HTTP response header.
For example, a server using a detailed ServerTokens configuration may send a header similar to:
Server: Apache/2.4.x (Unix)
If the server administrator configures ServerTokens Prod, Apache ordinarily reduces its identification header to:
Server: Apache
The corresponding directive is:
ServerTokens Prod
However, there is an important limitation: ServerTokens cannot be configured inside an .htaccess file.
Apache permits ServerTokens only in the main server configuration.
The setting applies to the entire Apache server rather than to an individual virtual host.
If you place ServerTokens Prod in an .htaccess file, Apache will reject the directive in that context, potentially causing a 500 Internal Server Error.
Therefore, website owners using shared hosting should not add ServerTokens Prod to their .htaccess files.
Instead, contact the hosting provider if you need changes to the server-wide ServerTokens configuration.
Step 5: Configure ServerTokens on a VPS or Dedicated Server
If you manage your own Apache server with root or administrative privileges, you can configure both directives in the main Apache configuration.
Depending on your operating system and installation, Apache configuration files may be located in directories such as /etc/apache2/ or /etc/httpd/.
For example, the following settings can be placed in an appropriate server-level Apache configuration file:
ServerSignature Off
ServerTokens Prod
The first directive disables the server signature footer. The second reduces the Server HTTP header to the Apache product name without displaying the detailed version.
Before applying changes, test your Apache configuration using a command such as:
apachectl configtest
On some systems, the equivalent command is:
apache2ctl configtest
If the configuration test succeeds, reload Apache using the service management command appropriate for your operating system.
On a typical Ubuntu or Debian installation, this may be:
sudo systemctl reload apache2
On a typical RHEL-compatible installation, it may be:
sudo systemctl reload httpd
These commands require appropriate administrative privileges.
The actual configuration paths and service names can vary between hosting environments.
Remember that ServerTokens Prod reduces the information exposed through Apache’s Server header.
It does not necessarily remove the header entirely.
Step 6: Check the HTTP Response Headers
You can inspect your website’s HTTP response headers using a terminal.
For example, run:
curl -I https://example.com
The curl command requests response headers from the specified URL.
Look for the Server header in the returned information. Depending on the server environment, you might see:
Server: Apache
If a detailed Apache version still appears, the ServerTokens setting may not have been changed at the server level.
A website may also use a CDN, reverse proxy, caching service, or load balancer.
In these environments, the Server header may identify the intermediary rather than the origin Apache server.
For example, if your website uses Cloudflare, the response headers visible to public visitors may be generated or modified by Cloudflare.
Also, the -I option sends an HTTP HEAD request.
It is useful for inspecting headers but does not display the body of the error page where an Apache server signature might appear.
Therefore, checking HTTP headers and checking server-generated error pages are two separate tests.
Common Problems When Disabling Server Signatures
One common problem is receiving a 500 Internal Server Error after modifying the .htaccess file.
This may happen if the directive is not permitted by the hosting provider’s Apache configuration. Restore the backup and contact your provider if necessary.
Another common misunderstanding is expecting ServerSignature Off to remove Apache version information from HTTP response headers.
This directive affects the footer of server-generated documents, not the Server header.
Some website owners also attempt to use ServerTokens Prod inside .htaccess.
This is not supported by Apache and should be avoided.
If your website uses Nginx instead of Apache, the .htaccess file will not control Nginx behavior.
Nginx has its own configuration directives, including server_tokens, for managing certain server identification information.
Likewise, when Apache operates behind another web server or reverse proxy, the externally visible response may not reflect Apache’s configuration directly.
Finally, disabling server signatures may not change the appearance of WordPress error pages because those pages are frequently generated by WordPress rather than by Apache itself.
Does Disabling the Server Signature Improve Website Security?
Disabling unnecessary server identification information can be useful, but its security benefits are limited.
Attackers do not need an exact Apache version number to attempt common attacks.
They may also identify server software through HTTP behavior, configuration characteristics, or other techniques.
More important security practices include keeping Apache and other server software updated, applying security patches, restricting unnecessary access, protecting administrative accounts, maintaining reliable backups, and monitoring suspicious activity.
Website owners should also keep WordPress core, themes, and plugins updated when using WordPress.
Treat ServerSignature Off as a small configuration improvement rather than a complete website security solution.
Conclusion
Disabling the Apache server signature is straightforward when your hosting environment supports the necessary .htaccess directive.
Simply add the following line to your website’s .htaccess file:
ServerSignature Off
This setting prevents Apache from appending its server identification footer to supported server-generated documents.
If you administer a VPS or dedicated Apache server, you can also configure ServerTokens Prod at the server level to reduce version information in HTTP response headers.
Remember that ServerSignature and ServerTokens serve different purposes, and only ServerSignature can be configured through .htaccess.
By understanding these settings and combining them with proper server maintenance, you can reduce unnecessary information exposure while keeping your Apache hosting environment properly configured.