Resolving "missing HSTS" or "missing HTTP Strict Transport Security" on WebSphere

Steps

1. Determine whether your applications and topology are compatible with HTTP Strict Transport Security (HSTS)
   1. Carefully review the Strict Transport Security header and protocol (HSTS)
      In short, HSTS tells browsers to force HTTPS even when accessing non-secure URLS on a given hostname. The HSTS header is cached by the browser over a duration specified in the response header.
   2. Review the hostnames and ports involved in the vulnerability report and determine what applications they represent
   3. Determine whether all of the applications are intended to run exclusively over HTTPS.
      If any applications must continue to use HTTP, you cannot enable HSTS.
   4. Determine the client-facing URLs used by the applications for both HTTP and HTTPS.
      For example, clients can use https://example.com/ to access your application implicitly over 443 or they might instead use an explicit port such as https://example.com:9043/
      Caution: If you use either a non-default HTTP or HTTPS port, HSTS may result in an unreachable website if the HTTP URL is ever used:
      1. If the HTTPS port is non-default, requests to HTTP ports will result in the default port (443) being used instead.
      2. If the HTTP port is non-default, requests to the HTTP port will result in the same port being accessed via HTTPS which will not succeed with IHS nor WAS.
2. If your applications and topology are compatible with HSTS, configure the Strict-Transport-Security header.
   Note: To satisfy a scanner or pen test, it may be necessary to implement HSTS in multiple places. For example, if the change is made only to IHS but application server is scanned directly, the false positive will need to be perpetually accounted for. Furthermore, some scan results of WAS ports that are not accessed by interactive browsers will also produce a false positive result, since HSTS is not meaningful.
   • If your application server is accessed via IBM HTTP Server, HSTS can be configured in httpd.conf. Specifying the header in IHS is more flexible and does not require any particular maintenance level, but there will be no change to a direct scan of the application server ports.  
      https://www.ibm.com/support/knowledgecenter/SSAW57_9.0.5/com.ibm.websphere.ihs.doc/ihs/tihs_hsts.html
   • The application server can also be configured to send the HSTS header: 
     https://www.ibm.com/support/knowledgecenter/SSEQTP_liberty/com.ibm.websphere.wlp.doc/ae/twlp_sec_hsts.html (Liberty 16.0.0.4 and later)
     https://www.ibm.com/support/knowledgecenter/SSAW57_9.0.5/com.ibm.websphere.nd.multiplatform.doc/ae/tsec_hsts.html  (8.5.5.18, 9.0.0.2, and later via PI67099) 
3. Confirm the HSTS header is present in the HTTPS response
   • Use your browsers developer tools or a command line HTTP client and look for a response header named Strict-Transport-Security.  
   • Access your application once over HTTPS, then access the same application over HTTP. Verify your browser automatically changes the URL to HTTPS over port 443.
4. Test the affected applications.