Does it makes sense from a security perspective to remove the Server HTTP header?
Clash Royale CLAN TAG#URR8PPP
up vote
6
down vote
favorite
I'm using Varnish and I'm not quite sure if I should also remove the Server: nginx
HTTP header. Why do someone needs to know that I'm using NGINX? Is it ok to remove this HTTP header from the response or is it needed somewhere? From a security perspective it's probably better to do so?
nginx http varnish http-headers
add a comment |Â
up vote
6
down vote
favorite
I'm using Varnish and I'm not quite sure if I should also remove the Server: nginx
HTTP header. Why do someone needs to know that I'm using NGINX? Is it ok to remove this HTTP header from the response or is it needed somewhere? From a security perspective it's probably better to do so?
nginx http varnish http-headers
I just remove the Server and similar headers. The server header is pretty meaningless anyway then a request might go through a series of load-balancers, caches, reverse proxies and middleware.
â Cameron Kerr
Aug 10 at 22:33
Yes, why should you reveal more information than needed, no matter if it "security by obscurity".
â chevallier
Aug 11 at 8:12
add a comment |Â
up vote
6
down vote
favorite
up vote
6
down vote
favorite
I'm using Varnish and I'm not quite sure if I should also remove the Server: nginx
HTTP header. Why do someone needs to know that I'm using NGINX? Is it ok to remove this HTTP header from the response or is it needed somewhere? From a security perspective it's probably better to do so?
nginx http varnish http-headers
I'm using Varnish and I'm not quite sure if I should also remove the Server: nginx
HTTP header. Why do someone needs to know that I'm using NGINX? Is it ok to remove this HTTP header from the response or is it needed somewhere? From a security perspective it's probably better to do so?
nginx http varnish http-headers
nginx http varnish http-headers
edited Aug 11 at 4:27
cat
1137
1137
asked Aug 10 at 19:44
chevallier
228210
228210
I just remove the Server and similar headers. The server header is pretty meaningless anyway then a request might go through a series of load-balancers, caches, reverse proxies and middleware.
â Cameron Kerr
Aug 10 at 22:33
Yes, why should you reveal more information than needed, no matter if it "security by obscurity".
â chevallier
Aug 11 at 8:12
add a comment |Â
I just remove the Server and similar headers. The server header is pretty meaningless anyway then a request might go through a series of load-balancers, caches, reverse proxies and middleware.
â Cameron Kerr
Aug 10 at 22:33
Yes, why should you reveal more information than needed, no matter if it "security by obscurity".
â chevallier
Aug 11 at 8:12
I just remove the Server and similar headers. The server header is pretty meaningless anyway then a request might go through a series of load-balancers, caches, reverse proxies and middleware.
â Cameron Kerr
Aug 10 at 22:33
I just remove the Server and similar headers. The server header is pretty meaningless anyway then a request might go through a series of load-balancers, caches, reverse proxies and middleware.
â Cameron Kerr
Aug 10 at 22:33
Yes, why should you reveal more information than needed, no matter if it "security by obscurity".
â chevallier
Aug 11 at 8:12
Yes, why should you reveal more information than needed, no matter if it "security by obscurity".
â chevallier
Aug 11 at 8:12
add a comment |Â
3 Answers
3
active
oldest
votes
up vote
12
down vote
accepted
RFC 7231 says about the Server header:
An origin server MAY generate a Server field in its responses.
MAY is interpreted as in RFC 2119:
- MAY This word, or the adjective "OPTIONAL", mean that an item is
truly optional. One vendor may choose to include the item because a
particular marketplace requires it or because the vendor feels that
it enhances the product while another vendor may omit the same item.
An implementation which does not include a particular option MUST be
prepared to interoperate with another implementation which does
include the option, though perhaps with reduced functionality. In the
same vein an implementation which does include a particular option
MUST be prepared to interoperate with another implementation which
does not include the option (except, of course, for the feature the
option provides.)
It is therefore perfectly fine to restrict or remove the Server response header. Of course it's a good idea to be aware of what you might be giving up by doing so. For that, go back to RFC 7231:
The "Server" header field contains information about the software
used by the origin server to handle the request, which is often used
by clients to help identify the scope of reported interoperability
problems, to work around or tailor requests to avoid particular
server limitations, and for analytics regarding server or operating
system use. An origin server MAY generate a Server field in its
responses.Server = product *( RWS ( product / comment ) )
The Server field-value consists of one or more product identifiers,
each followed by zero or more comments (Section 3.2 of [RFC7230]),
which together identify the origin server software and its
significant subproducts. By convention, the product identifiers are
listed in decreasing order of their significance for identifying the
origin server software. Each product identifier consists of a name
and optional version, as defined in Section 5.5.3.
Example:
Server: CERN/3.0 libwww/2.17
An origin server SHOULD NOT generate a Server field containing
needlessly fine-grained detail and SHOULD limit the addition of
subproducts by third parties. Overly long and detailed Server field
values increase response latency and potentially reveal internal
implementation details that might make it (slightly) easier for
attackers to find and exploit known security holes.
Though in practice, attackers don't really check the Server: header. They just try every security exploit they know of, whether your server gives any indication of being vulnerable or not. Removing the Server: header is a security by obscurity action, and an almost entirely ineffective one. But if it makes you feel better, or you're being told to do it by your boss or an auditor, go for it. Just don't expect it to result in any significant improvement to your security posture.
For example, nmap
can identify a web server with fairly good accuracy even when it's configured to not send a Server
header at all, or when the header content is completely bogus. Try it yourself with nmap -sV -P0 -p 80,443 <IP address>
.
add a comment |Â
up vote
2
down vote
The Server
HTTP header only serves one purpose - identification. It is not required anywhere for running your website properly, and by removing it, nothing is going to break.
It reveals the internal server infrastructure, and thus leaks security information that may be useful for potential intrusion.
After gaining knowledge of your web server software, via Server
HTTP header, the potential intruder can search your web server's publicly known vulnerabilities. Then they can use this information in conjunction with any other information they might gain (e.g. through scanning) - to build a proper attack vector.
Thus, you may want to remove the Server
header altogther, e.g. remove it in nginx.
add a comment |Â
up vote
1
down vote
If you have "server_tokens off" in your config (and it seems you do since there's only 'nginx' and not say 'nginx/1.13.11'), then it's OK to leave things as they are now. The problem could appear if you have a vulnerable version, and a bad person could use this info to exploit the vulnerability, but for that your nginx should be publicly accessible. So in a nutshell, use "server_tokens off;" and do no open nginx port for all IPs but for Varnish only, and you should be safe.
Yes, true. But why useserver
at all? What for? It simply reveals more information than necessary. I don't see any reason to keep that header.
â chevallier
Aug 10 at 19:59
1
It's OK to remove it. But it would not be a problem if you leave it. In most real world cases it's there. Anyway it's up to you.
â user3120146
Aug 12 at 14:16
add a comment |Â
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
12
down vote
accepted
RFC 7231 says about the Server header:
An origin server MAY generate a Server field in its responses.
MAY is interpreted as in RFC 2119:
- MAY This word, or the adjective "OPTIONAL", mean that an item is
truly optional. One vendor may choose to include the item because a
particular marketplace requires it or because the vendor feels that
it enhances the product while another vendor may omit the same item.
An implementation which does not include a particular option MUST be
prepared to interoperate with another implementation which does
include the option, though perhaps with reduced functionality. In the
same vein an implementation which does include a particular option
MUST be prepared to interoperate with another implementation which
does not include the option (except, of course, for the feature the
option provides.)
It is therefore perfectly fine to restrict or remove the Server response header. Of course it's a good idea to be aware of what you might be giving up by doing so. For that, go back to RFC 7231:
The "Server" header field contains information about the software
used by the origin server to handle the request, which is often used
by clients to help identify the scope of reported interoperability
problems, to work around or tailor requests to avoid particular
server limitations, and for analytics regarding server or operating
system use. An origin server MAY generate a Server field in its
responses.Server = product *( RWS ( product / comment ) )
The Server field-value consists of one or more product identifiers,
each followed by zero or more comments (Section 3.2 of [RFC7230]),
which together identify the origin server software and its
significant subproducts. By convention, the product identifiers are
listed in decreasing order of their significance for identifying the
origin server software. Each product identifier consists of a name
and optional version, as defined in Section 5.5.3.
Example:
Server: CERN/3.0 libwww/2.17
An origin server SHOULD NOT generate a Server field containing
needlessly fine-grained detail and SHOULD limit the addition of
subproducts by third parties. Overly long and detailed Server field
values increase response latency and potentially reveal internal
implementation details that might make it (slightly) easier for
attackers to find and exploit known security holes.
Though in practice, attackers don't really check the Server: header. They just try every security exploit they know of, whether your server gives any indication of being vulnerable or not. Removing the Server: header is a security by obscurity action, and an almost entirely ineffective one. But if it makes you feel better, or you're being told to do it by your boss or an auditor, go for it. Just don't expect it to result in any significant improvement to your security posture.
For example, nmap
can identify a web server with fairly good accuracy even when it's configured to not send a Server
header at all, or when the header content is completely bogus. Try it yourself with nmap -sV -P0 -p 80,443 <IP address>
.
add a comment |Â
up vote
12
down vote
accepted
RFC 7231 says about the Server header:
An origin server MAY generate a Server field in its responses.
MAY is interpreted as in RFC 2119:
- MAY This word, or the adjective "OPTIONAL", mean that an item is
truly optional. One vendor may choose to include the item because a
particular marketplace requires it or because the vendor feels that
it enhances the product while another vendor may omit the same item.
An implementation which does not include a particular option MUST be
prepared to interoperate with another implementation which does
include the option, though perhaps with reduced functionality. In the
same vein an implementation which does include a particular option
MUST be prepared to interoperate with another implementation which
does not include the option (except, of course, for the feature the
option provides.)
It is therefore perfectly fine to restrict or remove the Server response header. Of course it's a good idea to be aware of what you might be giving up by doing so. For that, go back to RFC 7231:
The "Server" header field contains information about the software
used by the origin server to handle the request, which is often used
by clients to help identify the scope of reported interoperability
problems, to work around or tailor requests to avoid particular
server limitations, and for analytics regarding server or operating
system use. An origin server MAY generate a Server field in its
responses.Server = product *( RWS ( product / comment ) )
The Server field-value consists of one or more product identifiers,
each followed by zero or more comments (Section 3.2 of [RFC7230]),
which together identify the origin server software and its
significant subproducts. By convention, the product identifiers are
listed in decreasing order of their significance for identifying the
origin server software. Each product identifier consists of a name
and optional version, as defined in Section 5.5.3.
Example:
Server: CERN/3.0 libwww/2.17
An origin server SHOULD NOT generate a Server field containing
needlessly fine-grained detail and SHOULD limit the addition of
subproducts by third parties. Overly long and detailed Server field
values increase response latency and potentially reveal internal
implementation details that might make it (slightly) easier for
attackers to find and exploit known security holes.
Though in practice, attackers don't really check the Server: header. They just try every security exploit they know of, whether your server gives any indication of being vulnerable or not. Removing the Server: header is a security by obscurity action, and an almost entirely ineffective one. But if it makes you feel better, or you're being told to do it by your boss or an auditor, go for it. Just don't expect it to result in any significant improvement to your security posture.
For example, nmap
can identify a web server with fairly good accuracy even when it's configured to not send a Server
header at all, or when the header content is completely bogus. Try it yourself with nmap -sV -P0 -p 80,443 <IP address>
.
add a comment |Â
up vote
12
down vote
accepted
up vote
12
down vote
accepted
RFC 7231 says about the Server header:
An origin server MAY generate a Server field in its responses.
MAY is interpreted as in RFC 2119:
- MAY This word, or the adjective "OPTIONAL", mean that an item is
truly optional. One vendor may choose to include the item because a
particular marketplace requires it or because the vendor feels that
it enhances the product while another vendor may omit the same item.
An implementation which does not include a particular option MUST be
prepared to interoperate with another implementation which does
include the option, though perhaps with reduced functionality. In the
same vein an implementation which does include a particular option
MUST be prepared to interoperate with another implementation which
does not include the option (except, of course, for the feature the
option provides.)
It is therefore perfectly fine to restrict or remove the Server response header. Of course it's a good idea to be aware of what you might be giving up by doing so. For that, go back to RFC 7231:
The "Server" header field contains information about the software
used by the origin server to handle the request, which is often used
by clients to help identify the scope of reported interoperability
problems, to work around or tailor requests to avoid particular
server limitations, and for analytics regarding server or operating
system use. An origin server MAY generate a Server field in its
responses.Server = product *( RWS ( product / comment ) )
The Server field-value consists of one or more product identifiers,
each followed by zero or more comments (Section 3.2 of [RFC7230]),
which together identify the origin server software and its
significant subproducts. By convention, the product identifiers are
listed in decreasing order of their significance for identifying the
origin server software. Each product identifier consists of a name
and optional version, as defined in Section 5.5.3.
Example:
Server: CERN/3.0 libwww/2.17
An origin server SHOULD NOT generate a Server field containing
needlessly fine-grained detail and SHOULD limit the addition of
subproducts by third parties. Overly long and detailed Server field
values increase response latency and potentially reveal internal
implementation details that might make it (slightly) easier for
attackers to find and exploit known security holes.
Though in practice, attackers don't really check the Server: header. They just try every security exploit they know of, whether your server gives any indication of being vulnerable or not. Removing the Server: header is a security by obscurity action, and an almost entirely ineffective one. But if it makes you feel better, or you're being told to do it by your boss or an auditor, go for it. Just don't expect it to result in any significant improvement to your security posture.
For example, nmap
can identify a web server with fairly good accuracy even when it's configured to not send a Server
header at all, or when the header content is completely bogus. Try it yourself with nmap -sV -P0 -p 80,443 <IP address>
.
RFC 7231 says about the Server header:
An origin server MAY generate a Server field in its responses.
MAY is interpreted as in RFC 2119:
- MAY This word, or the adjective "OPTIONAL", mean that an item is
truly optional. One vendor may choose to include the item because a
particular marketplace requires it or because the vendor feels that
it enhances the product while another vendor may omit the same item.
An implementation which does not include a particular option MUST be
prepared to interoperate with another implementation which does
include the option, though perhaps with reduced functionality. In the
same vein an implementation which does include a particular option
MUST be prepared to interoperate with another implementation which
does not include the option (except, of course, for the feature the
option provides.)
It is therefore perfectly fine to restrict or remove the Server response header. Of course it's a good idea to be aware of what you might be giving up by doing so. For that, go back to RFC 7231:
The "Server" header field contains information about the software
used by the origin server to handle the request, which is often used
by clients to help identify the scope of reported interoperability
problems, to work around or tailor requests to avoid particular
server limitations, and for analytics regarding server or operating
system use. An origin server MAY generate a Server field in its
responses.Server = product *( RWS ( product / comment ) )
The Server field-value consists of one or more product identifiers,
each followed by zero or more comments (Section 3.2 of [RFC7230]),
which together identify the origin server software and its
significant subproducts. By convention, the product identifiers are
listed in decreasing order of their significance for identifying the
origin server software. Each product identifier consists of a name
and optional version, as defined in Section 5.5.3.
Example:
Server: CERN/3.0 libwww/2.17
An origin server SHOULD NOT generate a Server field containing
needlessly fine-grained detail and SHOULD limit the addition of
subproducts by third parties. Overly long and detailed Server field
values increase response latency and potentially reveal internal
implementation details that might make it (slightly) easier for
attackers to find and exploit known security holes.
Though in practice, attackers don't really check the Server: header. They just try every security exploit they know of, whether your server gives any indication of being vulnerable or not. Removing the Server: header is a security by obscurity action, and an almost entirely ineffective one. But if it makes you feel better, or you're being told to do it by your boss or an auditor, go for it. Just don't expect it to result in any significant improvement to your security posture.
For example, nmap
can identify a web server with fairly good accuracy even when it's configured to not send a Server
header at all, or when the header content is completely bogus. Try it yourself with nmap -sV -P0 -p 80,443 <IP address>
.
edited Aug 10 at 20:57
answered Aug 10 at 20:13
Michael Hamptonâ¦
157k25290588
157k25290588
add a comment |Â
add a comment |Â
up vote
2
down vote
The Server
HTTP header only serves one purpose - identification. It is not required anywhere for running your website properly, and by removing it, nothing is going to break.
It reveals the internal server infrastructure, and thus leaks security information that may be useful for potential intrusion.
After gaining knowledge of your web server software, via Server
HTTP header, the potential intruder can search your web server's publicly known vulnerabilities. Then they can use this information in conjunction with any other information they might gain (e.g. through scanning) - to build a proper attack vector.
Thus, you may want to remove the Server
header altogther, e.g. remove it in nginx.
add a comment |Â
up vote
2
down vote
The Server
HTTP header only serves one purpose - identification. It is not required anywhere for running your website properly, and by removing it, nothing is going to break.
It reveals the internal server infrastructure, and thus leaks security information that may be useful for potential intrusion.
After gaining knowledge of your web server software, via Server
HTTP header, the potential intruder can search your web server's publicly known vulnerabilities. Then they can use this information in conjunction with any other information they might gain (e.g. through scanning) - to build a proper attack vector.
Thus, you may want to remove the Server
header altogther, e.g. remove it in nginx.
add a comment |Â
up vote
2
down vote
up vote
2
down vote
The Server
HTTP header only serves one purpose - identification. It is not required anywhere for running your website properly, and by removing it, nothing is going to break.
It reveals the internal server infrastructure, and thus leaks security information that may be useful for potential intrusion.
After gaining knowledge of your web server software, via Server
HTTP header, the potential intruder can search your web server's publicly known vulnerabilities. Then they can use this information in conjunction with any other information they might gain (e.g. through scanning) - to build a proper attack vector.
Thus, you may want to remove the Server
header altogther, e.g. remove it in nginx.
The Server
HTTP header only serves one purpose - identification. It is not required anywhere for running your website properly, and by removing it, nothing is going to break.
It reveals the internal server infrastructure, and thus leaks security information that may be useful for potential intrusion.
After gaining knowledge of your web server software, via Server
HTTP header, the potential intruder can search your web server's publicly known vulnerabilities. Then they can use this information in conjunction with any other information they might gain (e.g. through scanning) - to build a proper attack vector.
Thus, you may want to remove the Server
header altogther, e.g. remove it in nginx.
answered Aug 11 at 9:34
Daniel V.
5971310
5971310
add a comment |Â
add a comment |Â
up vote
1
down vote
If you have "server_tokens off" in your config (and it seems you do since there's only 'nginx' and not say 'nginx/1.13.11'), then it's OK to leave things as they are now. The problem could appear if you have a vulnerable version, and a bad person could use this info to exploit the vulnerability, but for that your nginx should be publicly accessible. So in a nutshell, use "server_tokens off;" and do no open nginx port for all IPs but for Varnish only, and you should be safe.
Yes, true. But why useserver
at all? What for? It simply reveals more information than necessary. I don't see any reason to keep that header.
â chevallier
Aug 10 at 19:59
1
It's OK to remove it. But it would not be a problem if you leave it. In most real world cases it's there. Anyway it's up to you.
â user3120146
Aug 12 at 14:16
add a comment |Â
up vote
1
down vote
If you have "server_tokens off" in your config (and it seems you do since there's only 'nginx' and not say 'nginx/1.13.11'), then it's OK to leave things as they are now. The problem could appear if you have a vulnerable version, and a bad person could use this info to exploit the vulnerability, but for that your nginx should be publicly accessible. So in a nutshell, use "server_tokens off;" and do no open nginx port for all IPs but for Varnish only, and you should be safe.
Yes, true. But why useserver
at all? What for? It simply reveals more information than necessary. I don't see any reason to keep that header.
â chevallier
Aug 10 at 19:59
1
It's OK to remove it. But it would not be a problem if you leave it. In most real world cases it's there. Anyway it's up to you.
â user3120146
Aug 12 at 14:16
add a comment |Â
up vote
1
down vote
up vote
1
down vote
If you have "server_tokens off" in your config (and it seems you do since there's only 'nginx' and not say 'nginx/1.13.11'), then it's OK to leave things as they are now. The problem could appear if you have a vulnerable version, and a bad person could use this info to exploit the vulnerability, but for that your nginx should be publicly accessible. So in a nutshell, use "server_tokens off;" and do no open nginx port for all IPs but for Varnish only, and you should be safe.
If you have "server_tokens off" in your config (and it seems you do since there's only 'nginx' and not say 'nginx/1.13.11'), then it's OK to leave things as they are now. The problem could appear if you have a vulnerable version, and a bad person could use this info to exploit the vulnerability, but for that your nginx should be publicly accessible. So in a nutshell, use "server_tokens off;" and do no open nginx port for all IPs but for Varnish only, and you should be safe.
answered Aug 10 at 19:54
user3120146
612
612
Yes, true. But why useserver
at all? What for? It simply reveals more information than necessary. I don't see any reason to keep that header.
â chevallier
Aug 10 at 19:59
1
It's OK to remove it. But it would not be a problem if you leave it. In most real world cases it's there. Anyway it's up to you.
â user3120146
Aug 12 at 14:16
add a comment |Â
Yes, true. But why useserver
at all? What for? It simply reveals more information than necessary. I don't see any reason to keep that header.
â chevallier
Aug 10 at 19:59
1
It's OK to remove it. But it would not be a problem if you leave it. In most real world cases it's there. Anyway it's up to you.
â user3120146
Aug 12 at 14:16
Yes, true. But why use
server
at all? What for? It simply reveals more information than necessary. I don't see any reason to keep that header.â chevallier
Aug 10 at 19:59
Yes, true. But why use
server
at all? What for? It simply reveals more information than necessary. I don't see any reason to keep that header.â chevallier
Aug 10 at 19:59
1
1
It's OK to remove it. But it would not be a problem if you leave it. In most real world cases it's there. Anyway it's up to you.
â user3120146
Aug 12 at 14:16
It's OK to remove it. But it would not be a problem if you leave it. In most real world cases it's there. Anyway it's up to you.
â user3120146
Aug 12 at 14:16
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f925892%2fdoes-it-makes-sense-from-a-security-perspective-to-remove-the-server-http-header%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
I just remove the Server and similar headers. The server header is pretty meaningless anyway then a request might go through a series of load-balancers, caches, reverse proxies and middleware.
â Cameron Kerr
Aug 10 at 22:33
Yes, why should you reveal more information than needed, no matter if it "security by obscurity".
â chevallier
Aug 11 at 8:12