A web application only sets the HSTS header in responses to requests to /assets/*. Any other response does not include the HSTS header.
While it does seem insecure at first, any browser opening the index page will quickly follow up loading all the assets, which then results in the HSTS header being seen and respected for all future requests.
Is there something I am missing? Is this strange setup fine?
It would be recommendable to have the HSTS header set on every HTTPS response, but this effectively provides the same level of security, because the HSTS policy is cached for the max-age seconds. It's defined that the lack of Strict-Transport-Security header doesn't cause deletion of the policy, but only settings a zero value for the max-age (RFC 6796 6.1.1, 5.3 & 12.5). Also, settings a value too low causes it to expire too soon.
These setups can protect a user that has visited the page on a trusted network (or a browser seen the HSTS header on it, to be more precise) within the max-age seconds. If the URLs providing the HSTS header are loaded on every visit, this wouldn't really compromise this. Despite that, I can't see any reason not to move this configuration on hostname level, and it might just be a mistake, too.
However, this prevents from protecting the users before they have ever visited the site (which would be the next step & level), as the presense of Strict-Transport-Security with both includeSubDomains and preload on request to / is mandatory, if you wish to add the domain to an HSTS Pre-Loaded List. This is the only way to protect the whole example.com, *.example.com, *.*.example.com etc. in advance. In addition, hstspreload.org requires that the max-age must be at least 31536000 seconds (1 year).
It does seem strange. Here are two scenarios to illustrate.
Scenario One
Maybe the browser settings may be such that assets are not loaded, e.g., a mobile device on mobile data, where assets might not be loaded to conserve bandwidth.
Then you would be open to all the vulnerabilities that HSTS protects against.
Scenario Two (This scenario edited after discussion in comments below)
Moreover, even without such a restriction on assets loading, without the HSTS header for the index page, your leave your web app open to attacks, the result of which is that an attacker might already have succeeded in replacing the initial response with an arbitrary page of their choosing, over http. If this happens for the load of the index page, then whatever asset loading that is supposed to happen next, becomes irrelevant, so your browser never even requests for those assets, and never see the HSTS header in the responses.
As a concrete example, consider an SSL-stripping man-in-the-middle (MiTM) attacks. With SSL stripping MiTM attacks, a https connection is converted to http by the MiTM. Now, what is to prevent the attacker from simply ignoring the HSTS header coming from your web app its response, and presenting their arbitrary response back to the client over http without the HSTS header? That's where preload lists come into the picture.
All the major browsers implement HSTS preload lists that include known sites supporting HSTS. Thus, the browser doesn't have to rely on receiving the actual response from the site in order to know that it implements HSTS, so the browser will enforce the use of https. So, how are these HSTS preload lists generated for use by the browsers?
In the case of firefox, for example (see blog.mozilla.org/security),
To build our preload list, a request is sent to every host with ‘mode: “force-https”‘ on Chrome’s list. Only if a host responds with a valid HSTS header ..
so not including the HSTS header in the web app's index page may cause it to be excluded from the preload list, leaving the web app open to attacks that HSTS (implemented with preload lists) would normally protect against.
