What is the difference between setting HSTS on a web server and trying to handle it in client-side React code?

Why HSTS belongs in the response path, not in React

HSTS is a browser-enforced transport policy, so the control only becomes real when the browser receives it as part of an HTTP response. That is why it belongs at the web server, reverse proxy, CDN edge, or SSR layer, not in client-side React. React runs after the page is already loading, so it cannot reliably create the trust boundary HSTS is meant to enforce.

The practical distinction is authority. A server can instruct the browser to remember that a host must only be contacted over HTTPS for a defined period, which changes future navigation behaviour before any page script executes. Client-side code can display warnings, redirect users, or encourage HTTPS use, but it cannot define browser security policy. For the same reason, attempting to “handle HSTS” in React gives you an appearance of control without the browser guarantee.

That gap matters most on first contact and downgrade paths. If the browser has not already cached an HSTS policy, the first request still depends on transport-layer handling outside the React app. If the policy is set correctly on the response, the browser will stop using HTTP for that host on later visits, which is the whole point of the mechanism.

For adjacent implementation guidance on transport and deployment boundaries, compare the HSTS discussion with OWASP Cheat Sheet Series and the browser-facing policy model described by NIST Cybersecurity Framework 2.0.

What changes when HSTS is set at the edge or on the server

Setting HSTS at the server or edge makes the policy part of the site’s actual delivery path. That means it can be applied consistently to the responses that matter, including redirects, SSR output, and API responses from the same origin. It also means the browser can enforce the policy independently of whether the frontend application is loaded, hydrated, or even functioning correctly.

In contrast, client-side React is constrained by the browser sandbox and by execution timing. By the time React code runs, the browser has already decided how to fetch the document, follow redirects, and interpret transport security headers. React can influence user experience, but it cannot retroactively convert an insecure transport decision into an enforced browser policy.

This distinction also helps with operational consistency. Security controls that live in application code tend to drift when teams split frontend and backend responsibilities. Headers configured at the edge or server layer are easier to audit, easier to standardise across pages, and less likely to disappear when a component tree changes. That is the right place for a control whose job is to be universal and immediate.

A useful cross-check is whether the setting survives framework changes. If moving from React-only rendering to SSR, a gateway, or a CDN changes whether HSTS is present, the control was never truly embedded in the right layer. The browser should receive the header regardless of how the page is rendered.

For the server-side deployment and policy boundary, NIST Cybersecurity Framework 2.0 and OWASP Cheat Sheet Series both support the general principle that security controls belong where the trust decision is made.

How to evaluate the implementation choice in practice

The decision rule is simple: if the control must be enforced by the browser, it must be emitted by something that speaks for the origin, not by page JavaScript. For HSTS, that means the server, gateway, CDN, or SSR layer that returns the response. React can still be useful for user-facing messaging or for checking that HTTPS is present, but those are secondary tasks, not policy enforcement.

One common mistake is treating “we redirect to HTTPS in the app” as equivalent to HSTS. It is not. Redirect logic can help, but it still depends on a request reaching the application and does not create the same browser memory that HSTS does. Another mistake is assuming that any code running in the browser can “set security headers” in a meaningful way. It cannot, because headers are attached to responses, not to rendered components.

If you are reviewing an implementation, verify the actual network response, not just the source tree. Check the header on the first response from the origin path you care about, confirm it is present across redirects and static asset delivery where relevant, and make sure it is being set by infrastructure that will remain in place after frontend refactors.

Practitioner takeaway: HSTS is a transport policy, so the right question is not where the React code lives but which layer can reliably send the response header every time the browser needs it.

Related resources from NHI Mgmt Group

• What is the difference between client-side route guards and server-side authorization in a single-page application?
• What is the difference between client-side attack surface monitoring and standard web application security testing?
• What is the difference between client-side guardrail integration and running guardrails on a dedicated server?
• What is the difference between server-side security controls and client-side protection for payment pages?