What modules of Helmet should I use in my REST Api

Question

Question:

Which Helmet modules should be used for a rest API?

Background:

I am building a Node/Express REST Api and keep seeing Helmet pop up as a security middleware I should be using. Looking at Helmet's documentation is looks like some of the modules (Content Security Policy, Cross Domain, ect) are only applicable to front end apps. Which modules should be used in Helmet for a rest API?

Answer 1

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:

1. Some of the headers are useful in non-browser use cases, like a REST API.
2. 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.