Features found in helmet, not in lusca?

[gavinengel]

I was just reviewing the features of helmetjs: https://www.npmjs.org/package/helmet

I see these features which don't appear to be a part of lusca. If that's true, are there plans to add them? Or perhaps is the recommended solution to simply use both lusca and helmet?

• crossdomain for serving crossdomain.xml: https://github.com/helmetjs/crossdomain
• hidePoweredBy to remove the X-Powered-By header: https://github.com/helmetjs/hide-powered-by
• ieNoOpen sets X-Download-Options for IE8+: https://github.com/helmetjs/ienoopen
• noCache to disable client-side caching: https://github.com/helmetjs/nocache
• noSniff to keep clients from sniffing the MIME type: https://github.com/helmetjs/dont-sniff-mimetype

[aredridel]

Those are so delightfully compartmentalized, I'd say just use those!

[gavinengel]

@aredridel Good point. Do you feel it's worthwhile to cover my bases by using both the helmet modules and lusca for an average REST API? I'm wondering if I should even bother unless a need arises. I prefer to use Strongloop's Loopback, by the way.

[aredridel]

Both are good, both cover different cases: Write down a quick security model. Decide what attacks you need to mitigate, and mitigate them. Without context, it's really hard to do security. It's not a checklist. I don't think there's an "average" API.

You also have to investigate the costs of these things.

• lusca:
  • CSRF protection, because if you authenticate with implicit authorization of requests, such as with browser cookies or HTTP Basic, any site the user visits while that's valid can trigger spoofed posts, even if it can't read the response. Costs: complicates design of third parties submitting to your API.
  • X-Frame options: Because controlling whether a site can be embedded is often important. (PayPal obviously wants to make sure you're in a trustable environment, and have to control things that would confuse users, so they don't give credentials to a phishing site). Costs: ability to use iframes freely within your site.
  • p3p: Privacy preferences aren't strictly security, but we're managing the user's trust of our site. Costs: maintenance.
  • hsts: Force SSL, because allowing the site to be accessed over non-SSL is often a way someone in the middle attacks a secured site, by forcing things to stay non-SSL. Costs: Dealing with places where SSL fails or old browsers.
  • xss: If you're displaying user-submitted content, adding headers to get IE8 to help you out is good. Costs: Escaping and filtering of content is still needed. Escaping is stupidly complex, and the number of moving parts gets to be a lot to keep in your head.
• helmetjs:
  • crossdomain: Control Flash-based communication channels, to prevent Flash from exfiltrating information. Costs: not a ton, but you have to be aware of it if you use Flash-based communication (perhaps including socket.io)
  • hidePoweredBy: Reduce information available to attackers using version numbers to find exploitable software. Costs: Reduces inspectability and auditability of your system.
  • noSniff: Keeps non-script resources from being executed as scripts. Costs: Means you have to dot your Is and cross your Ts with regard to mime types.
  • noCache: Not a security-related module. (I've got opinions that you've made a poor API design if you rely on this, but that's another matter entirely)
  • ieNoOpen: Not security-related, just controls the user experience to make IE do what you intend.

[aredridel]

One thing that neither set of modules addresses: rate limiting. That can be one of your biggest friends in designing a stable, resilient, secure API.

[gavinengel]

Wow. I thank you for that! Your notes are extremely helpful.

I was reviewing a slightly different solution of using a separate gateway to sit in front of any number of APIs (I suppose for people not using CloudFlare...) This way the security concerns can be addressed in a single project instead of inside every node REST API (and I suppose existing APIs written in other languages). Here is one example: https://github.com/strongloop/loopback-gateway

Aside from the user authentication in that project, I'd guess other features seem like they could be easily added to just about any other node framework. They include the rate limiter feature you mentioned in your last comment, too.

A final question if you wouldn't mind: Do you think it would be a bad idea to put the lusca/helmet packages on such a gateway instead of the APIs themselves?

[aredridel]

Not at all: just be aware of what security tasks require the application's knowledge. CSRF, for example, means the application has to pass a value with a request that an unrelated page can't guess, but a related one can include for verification.

XSS attack mitigation requires deep knowledge to fight well -- right down to what the expected output is in a given part of a page (html attribute, text, script, json -- there are so many escaping rules!) and whether or not that's restricted or not (came from the app or an end user) that doing it as a gateway is impossible, and even the middleware-based approaches are weak (lusca just triggers some IE headers to help out, doesn't even try to mitigate general cases)

X-frame options restrict your application. If your application fits within those constraints, the constraints can be applied outside -- but if part of your application needs to alter those options? You'll want them in app.

hidePoweredBy and p3p and hsts are good candidates for applying company-wide, and so a gateway makes a lot of sense.

[gavinengel]

Thanks again for your advice today.

[aredridel]

You are welcome! Good luck, and write down what you decide and why: it'll help you improve your security in the future if you have that as a reference.