tl;dr: the following might be useful for an API, though you could set more to be safe:
helmet.expectCt
, which sets the Expect-CT
header, is useful if the consumer of your API knows how to handle certificate transparency
helmet.frameguard
, which sets the X-Frame-Options
header, is useful if your API responses are ever put into an iframe
or similar. (I have run into this personally.)
helmet.hsts
, which sets the Strict-Transport-Security
header, helps keep users on HTTPS
helmet.noSniff
, which sets the X-Content-Type-Options
header, is useful in browsers that might try to auto-detect your API response's type and do something unexpected. (I have run into this personally.)
helmet.permittedCrossDomainPolicies
, which sets the X-Permitted-Cross-Domain-Policies
header, might be useful to protect your site against strange requests from Adobe products like Flash
Author of Helmet here.
I'd say there are two reasons to use Helmet (or the HTTP headers it sets) with an API:
- Some of the headers are useful in non-browser use cases, like a REST API.
- In case your response is ever loaded in a browser. For example, if a hacker puts it in an
<iframe>
and causes something unexpected to happen. (Old browsers sometimes have problems here, causing vulnerabilities.) You could also do it to future-proof your API in case it is ever loaded in the browser, even if it isn't today.
Helmet is just a collection of 13 smaller middlewares. Most of those set a single HTTP response header, and most of those headers are only useful in browsers. Some, however, are occasionally useful for APIs (REST or otherwise).
Let's enumerate them:
helmet.contentSecurityPolicy
, which sets the Content-Security-Policy
header, is probably not useful
helmet.dnsPrefetchControl
, which sets the X-DNS-Prefetch-Control
header, is probably not useful
helmet.expectCt
, which sets the Expect-CT
header, might be useful if the consumer of your API knows how to handle certificate transparency
helmet.featurePolicy
, which sets the Feature-Policy
header, is probably not useful
helmet.frameguard
, which sets the X-Frame-Options
header, might be useful in case your API responses are ever put into an iframe
or similar. (I have run into this personally.)
helmet.hidePoweredBy
, which removes the X-Powered-By
header, is probably not useful (it's not even that useful in browsers!)
helmet.hsts
, which sets the Strict-Transport-Security
header, might be useful to keep users on HTTPS
helmet.ieNoOpen
, which sets the X-Download-Options
header, is probably not useful
helmet.noCache
is going to be removed in future Helmet versions and isn't super useful for security anyway, so it's probably not useful
helmet.noSniff
, which sets the X-Content-Type-Options
header, might be useful in browsers that might try to auto-detect your API response's type and do something unexpected. (I have run into this personally.)
helmet.permittedCrossDomainPolicies
, which sets the X-Permitted-Cross-Domain-Policies
header, might be useful to protect your site against strange requests from Adobe products like Flash
helmet.referrerPolicy
, which sets the Referrer-Policy
header, is probably not useful
helmet.xssFilter
, which sets the X-XSS-Protection
header, is probably not useful
In summary: a few of them might be useful—might be worth setting a few of these headers just to be safe.