search

krakenjs / lusca

Application security for express apps.
Other
1.79k stars 139 forks source link

Is helmet needed with lusca? #127

Closed khaledosman closed 5 years ago

khaledosman commented 6 years ago

Are there any cases where I may need one over the other or is one of them enough? can someone please explain to me the difference?

oieduardorabelo commented 5 years ago

perhaps this can help you: https://github.com/krakenjs/lusca/issues/42

@aredridel answered a similar question a few years ago :)

khaledosman commented 5 years ago

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.

Thanks.. I guess its good to use both.

Helmet seems to do xss & hsts now aswell.. Their documentation shows which options they enable by default so its easier to tell which ones are missing and can be covered by lusca https://github.com/helmetjs/helmet#user-content-how-it-works