We occasionally get findings for not having HSTS enabled on our HTTPS interfaces, but since these interfaces are server to server only, would enabling HSTS make any difference security wise?
Does HTTP Strict Transport Security (HSTS) make any sense in server to server communication?
3It doesn't hurt to have it on, but honestly I don't even think most HTTP client libraries actually care about the HSTS headers.– André BorieApr 19, 2016 at 13:31
1One use of HSTS in servers that normally only serves other servers is if you sometimes access the API from a browser for debugging purpose (for example via postman or a custom written debug app), then you might forget to add https://. Other than that, I don't see any reason to use HSTS header in a server to server communication.– Lie RyanApr 19, 2016 at 15:43
The weakness HSTS is designed to protect against is clients that first connect to a server by making a request over HTTP, and are expected to be redirected to the HTTPS version (or a 404). An attacker can MitM that request and instead of sending the redirect send the (possibly modified) site over HTTP.
Connections over HTTP can be opened for many reasons:
- Attacks like SSL-strip.
- People entering the HTTP address into the URL bar
- Hardcoded links to HTTP.
Do any of these affect a server? The third one might, but it depends on whether you have full control of all the software that connects to your server or not.
If you have full control
Just make sure all URLs that are ever used are to HTTPS. If they are read from a config file, explicitly check that they are not HTTP. This eliminates the need for HSTS. While you are at it, you should make sure you only accept secure cipher suites and perhaps think about implementing certificate or public key pinning.
If you do not have full control
Let's say other people write software that connects to your server. You do not know if these people know what they are doing. They might accidentally make a HTTP request somewhere.
If the libraries they use actually interpret and enforce HSTS headers (it is the client that is responsible for enforcing HSTS) these people would be more safe with HSTS turned on. But it is still sort of an edge case - if you give 404 answers and not redirects on HTTP requests it is hard to imagine why anyone would write software that makes them. I also suspect most libraries ignore the HSTS headers. But who knows!
HSTS probably won't make a difference in your case, if nobody ever uses the interface using a browser.
If you control the client (which is the other server in your case), you can simply only request HTTPS URLs and never request HTTP requests. It is also questionable whether the client even supports HSTS. It is implemented in many browsers, but not many HTTP libraries.
One way it can make a difference is if the server redirects from HTTPS to HTTP. With HSTS enabled, supporting clients won't follow the redirect.
Since it sounds like you only want HTTPS, you may want to disable the HTTP service.
In a scenario where server and client applications were custom-developed and controlled there is no threat model that HSTS would mitigate.
Both sides of the transmission should be configured with proper certificates and should prevent protocol downgrade without relying on HSTS.
HSTS was introduced as a protection against bypassing SSL by disabling it completely, or downgrading the protocol to a lower (unsafe) version, in a scenario where users access remote servers of which they have information or technical skills to assess the protection level.
Finally, if a client application does not support HSTS, turning it on does not have any effect.