[docs] Readme should explain whether helmet is useful on a subroute

[mk-pmb]

Thanks for this great module, and for taking the responsibility to keep up to date with security header news!

I wonder whether I should use helmet in my API server. Any website shall be able to talk to that API server, so I'd probably not want to run helmet server-wide. However, for admin convenience it does have some sub-namespaces for hosting static files. Should I run helmet on those routes?
Then again, some headers may be useful even for my server as a whole, like the ones that tell browsers not to misinterpret a random JSON API reply as HTML and run JS in it.
It would be nice if you could advise on such situations in readme.

[EvanHahn]

This is a good question. This kind of question is challenging for me. How much should Helmet document, and how much should it leave to others? For example, I don't think Helmet should be the authority on the Content-Security-Policy header, but does that mean I should explain nothing about how it works? Your question gets to another wrinkle. How much should Helmet document about peoples' different app setups? There are so many ways to structure an app that it's hard to give something definitive. Can you think of a broader way to ask this question such that it can be generally applicable? Maybe something like, "What kinds of resources should I protect with Helmet?" or "Should I use Helmet for API routes? What about static files?"

[Rachaelhikes]

What kind of recourse should I protect with helmet?

[mk-pmb]

Your broader questions sound plausible and seem to widely overlap, but I'm probably not deep enough into latest webserver security to be helpful. Any my attempt of rewording could just as well lead you astray.

[EvanHahn]

Again, it's hard to give generic advice. But for most applications, here are the kinds of resources I protect with each header.

Note: I wrote this list quickly and haven't checked it. It may have errors! To be safe, set every header every time!

• Content-Security-Policy: HTML, SVG, worker scripts
• Cross-Origin-Embedder-Policy: HTML, SVG, and worker scripts
• Cross-Origin-Opener-Policy: HTML only
• Cross-Origin-Resource-Policy: all resources
• Origin-Agent-Cluster: HTML only
• Referrer-Policy: documents and stylesheets (and maybe scripts?)
• Strict-Transport-Security: all resources
• X-Content-Type-Options: all resources
• X-DNS-Prefetch-Control: HTML only
• X-Download-Options: all downloadable resources
• X-Frame-Options: HTML only
• X-Permitted-Cross-Domain-Policies: all resources (I believe?)
• X-Powered-By: all resources
• X-XSS-Protection: HTML only

Is this the kind of thing you're looking for?

[mk-pmb]

Oh, I see! It seems my initial distinction of static content vs. API routes was already off then, and instead I should distinguish by Content-Type. Should those for SVG also apply to XML and XHTML?

[EvanHahn]

I should distinguish by Content-Type

I think it's a little more complicated. For example, X-Download-Options is only really relevant if you're using Content-Disposition: attachment. (Though, to be fair, that header really only affects old Internet Explorer versions.) And some headers may make sense on all responses, API or not.

Should those for SVG also apply to XML and XHTML?

I believe they should be set for documents, which includes HTML, XHTML, and SVG. All of these can load resources and execute scripts. I'm not sure about XML—I don't know if browsers treat them as documents. (You can style XML responses, so maybe they do?)

[mk-pmb]

I tend to see XML files as documents, too. For example a wiki's recent changes page its pretty much the same concept whether you view the HTML or XML version.

For now, it looks like I can .use() helmet on the server level, and it won't interfere:

• X-Download-Options probably won't confuse any API client (bot or 3rd-party website), so that should not be a problem.
• The Content-Security-Policy I send should be irrelevant when a 3rd-party website makes API requests to my server, because their CSP is the one the browser will use.
• Originally I thought the Cross-Origin-* headers could conflict with the "enable CORS" module on my API routes, but a deeper look shows it only uses Access-Control-* so those are distinct. (Edit: …-Resource-Policy can still bite you, see below.)
• I might have to opt-out of X-Frame-Options for some routes that are meant to be iframed though.
  • For those, Content-Security-Policy might become relevant maybe.

[EvanHahn]

That sounds right.

In general, it's fine to use Helmet on every response. For example, Content-Security-Policy probably won't break a JSON API. And as you say: some headers, like X-Frame-Options or CSP's frame-ancestors directive, might not be what you want depending on your specific needs.

Does that answer your question?

[mk-pmb]

Yes, it does answer the original question. The obvious next follow-up question for the widget iframe to be embedable is, how can I exempt only some selected routes from some of the rules?

[EvanHahn]

This is more an Express question than a Helmet-specific question.

Experss doesn't offer an easy way to exempt specific routes from middleware. You have a few options:

• Conditionally skip the middleware. I have a basic guide for this on the Helmet docs.
• Conditionally set middleware options. I also have a basic guide for this.
• Override the headers for some routes. You might do something like res.removeHeader() for specific routes.

Does that help?

[mk-pmb]

Yes, perfect, thank you!
… well, almost. While making my PR, I discovered that actually Cross-Origin-Resource-Policy seems to interfere a lot with API servers, so I should probably disable that for any routes that are meant to be used by 3rd-party websites. → Draft

[EvanHahn]

Thanks, I'll take a look at this.