Why express-secure-headers

Security is hard. It’s not always obvious what needs doing, and the payoffs of good security are at best obscure.You should build your web apps protective enough to have no security issues or loopholes, thus eradicating the possibility of any malicious attack. In most cases, the developers must take the responsibility and put in every possible effort to identify the vulnerabilities and propose solutions, if any to address the issues prevailing in the apps.

express-secure-headers helps you secure your express js apps by setting various HTTP headers.

Security Features

✔ Cache Control Attack ✔ Cross-Origin Resource Sharing (CORS) ✔ X-Permitted-Cross-Domain-Policies ✔ DNS Prefetch Control ✔ Click Jacking Attack ✔ Strict-Transport-Security ✔ Mime Sniffing Attack ✔ X-Powered-By Attack ✔ XSS Attack

Quick start

First, You can install the package via composer:

Quick Example

Attack #1 Cache Control

Cache-control is an HTTP header that dictates browser caching behavior. In a nutshell, when someone visits a website, their browser will save certain resources, such as images and website data, in a store called the cache. When that user revisits the same website, cache-control sets the rules which determine whether that user will have those resources loaded from their local cache, or whether the browser will have to send a request to the server for fresh resources. In order to understand cache-control in greater depth, a basic understanding of browser caching and HTTP headers is required.

Attack #2 Cross-Origin Resource Sharing (CORS)

Cross-Origin Resource Sharing (CORS) is a mechanism that uses additional HTTP headers to tell a browser to let a web application running at one origin (domain) have permission to access selected resources from a server at a different origin. A web application executes a cross-origin HTTP request when it requests a resource that has a different origin (domain, protocol, and port) than its own origin.An example of a cross-origin request: The frontend JavaScript code for a web application served from http://domain-a.com uses XMLHttpRequest to make a request for http://api.domain-b.com/data.json

Attack #3 X-Permitted-Cross-Domain-Policies

Adobe Flash and Adobe Acrobat can load content from your domain even from other sites (in other words, cross-domain). This could cause unexpected data disclosure in rare cases or extra bandwidth usage.

Attack #4 DNS Prefetch Control

The X-DNS-Prefetch-Control HTTP response header controls DNS prefetching, a feature by which browsers proactively perform domain name resolution on both links that the user may choose to follow as well as URLs for items referenced by the document, including images, CSS, JavaScript, and so forth

Attack #5 Click Jacking Attack

The HTTP Strict-Transport-Security response header (often abbreviated as HSTS) lets a web site tell browsers that it should only be accessed using HTTPS, instead of using HTTP

Attack #7 Mime Sniffing Attack

MIME sniffing was, and still is, a technique used by some web browsers (primarily Internet Explorer) to examine the content of a particular asset. This is done for the purpose of determining an asset’s file format. This technique is useful in the event that there is not enough metadata information present for a particular asset, thus leaving the possibility that the browser interprets the asset incorrectly. Although MIME sniffing can be useful to determine an asset’s correct file format, it can also cause a security vulnerability. This vulnerability can be quite dangerous both for site owners as well as site visitors. This is because an attacker can leverage MIME sniffing to send an XSS (Cross Site Scripting) attack

Attack #8 X-Powered-By Attack

Hackers can exploit known vulnerabilities in Express js if they know you’re using it.

Attack #9 XSS Attack

Cross site scripting (XSS) is a common attack vector that injects malicious code into a vulnerable web application. XSS differs from other web attack vectors (e.g., SQL injections), in that it does not directly target the application itself. Instead, the users of the web application are the ones at risk. Depending on the severity of the attack, user accounts may be compromised, Trojan horse programs activated and page content modified, misleading users into willingly surrendering their private data. Finally, session cookies could be revealed