How to configure HSTS header for TYK API gateway

Hi guys,
Is there a way to configure HSTS header for TYK API gateway? When we perform a curl “curl -v https://(tyk-fqdn)/hello”, there is no HSTS header configured.

Hello @ljcheng84 and welcome to the community :tada:

You can add the Strict-Transport-Securityheader using the global headers section to any API you want HSTS enabled.

I see you are hitting the liveness check endpoint

“curl -v https://(tyk-fqdn)/hello”

There isn’t a global level where this can be added to the gateway. So this will need to be done for every API that you want to enable HSTS on.

However, you could implement a global-level workaround by using an API definition in Tyk as a root proxy. In Tyk you can refer from one API to another using a special URL scheme, which looks like tyk://<api-id>/ or tyk://<api-name>. This method is known as looping and it allows you to create a global API that listens on the root, e.g. “/”, and add headers which you need.

To make it work, you will also need to set internal flag for your APIs, so they will stop being published as real APIs on their listen path, and instead be available only via "tyk://" URLs.

The other alternative is to add headers via a thin reverse proxy server (such as nginx) or load balancer (if you use one) that sits in front of the Tyk Gateway.

Hope this helps.

Hi Olu,

Thanks for responding. We did not encounter any missing HSTS when triggering the API as typically the API endpoints are already enforced with HSTS. Thus when TYK trigger API to the endpoints, there is no issues.

The issue we suspect is as you mentioned the default endpoint of TYK API gateway as the HSTS header is missing when our security audit ran this command:
nmap -p 443 --script http-security-headers

Is there a way we can configured the default endpoint to add the HSTS header assuming we do not have additional proxy server setup in front of TYK gateway

As mentioned, you could define an API definition at the root ("listen_path": "/"). My tests showed that the behaviour has changed from what I earlier mentioned

The root path would be treated as a fallback when none of the configured listen paths or gateway API-provided routes match.

Hope this helps