- Cross-Site Scripting (XSS)
- Cross-Site Request Forgery (CSRF)
Below some packages in suggestion order that implements this protocol:
- Content Security Policy (CSP)
Content Security Policy is a mechanism designed to make applications more secure against common web vulnerabilities, particularly cross-site scripting. It is enabled by setting the Content-Security-Policy HTTP response header.
The core functionality of CSP can be divided into three areas:
Requiring that all scripts are safe and trusted by the application owner (ideally by making sure they match an unpredictable identifier specified in the policy called the CSP nonce),
Ensuring that page resources, such as images, stylesheets, or frames, are loaded from trusted sources,
Miscellaneous other security features: preventing the application from being framed by untrusted domains, transparently upgrading all resource requests to HTTPS, and others.
By adopting a strict policy, which prevents the loading of untrusted scripts or plugins, an application can add an important defense-in-depth layer against markup injection attacks. This documentation focuses on the XSS mitigation aspect of CSP because XSS is one of the most common and dangerous web vulnerabilities.
An application can define a policy by setting the following header:
Content-Security-Policy: default-src https:; script-src 'nonce-{random}'; object-src 'none'
To learn more check this link
Below some packages in suggestion order that implements this header:
- HTTP Strict Transport Security (HSTS)
The HTTP Strict-Transport-Security response header (often abbreviated as HSTS) is a security feature that lets a web site tell browsers that it should only be communicated with using HTTPS, instead of using HTTP.
Strict-Transport-Security: max-age= Strict-Transport-Security: max-age=; includeSubDomains Strict-Transport-Security: max-age=; preload
If a web site accepts a connection through HTTP and redirects to HTTPS, the user in this case may initially talk to the non-encrypted version of the site before being redirected, if, for example, the user types http://www.foo.com/ or even just foo.com.
This opens up the potential for a man-in-the-middle attack, where the redirect could be exploited to direct a user to a malicious site instead of the secure version of the original page.
The HTTP Strict Transport Security header lets a web site inform the browser that it should never load the site using HTTP and should automatically convert all attempts to access the site using HTTP to HTTPS requests instead.
To learn more check this link
Below some packages in suggestion order that implements this header:
-
X-FRAME-OPTIONS (Clickjacking protection)
The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a , <iframe> or . Sites can use this to avoid clickjacking attacks, by ensuring that their content is not embedded into other sites.
The added security is only provided if the user accessing the document is using a browser supporting X-Frame-Options.
There are three possible directives for X-Frame-Options:
X-Frame-Options: DENY X-Frame-Options: SAMEORIGIN X-Frame-Options: ALLOW-FROM https://example.com/
If a web site accepts a connection through HTTP and redirects to HTTPS, the user in this case may initially talk to the non-encrypted version of the site before being redirected, if, for example, the user types http://www.foo.com/ or even just foo.com.
This opens up the potential for a man-in-the-middle attack, where the redirect could be exploited to direct a user to a malicious site instead of the secure version of the original page.
The HTTP Strict Transport Security header lets a web site inform the browser that it should never load the site using HTTP and should automatically convert all attempts to access the site using HTTP to HTTPS requests instead.
To learn more check this link
Below some packages in suggestion order that implements this header:
The X-Content-Type-Options response HTTP header is a marker used by the server to indicate that the MIME types advertised in the Content-Type headers should not be changed and be followed. This allows to opt-out of MIME type sniffing, or, in other words, it is a way to say that the webmasters knew what they were doing.
This header was introduced by Microsoft in IE 8 as a way for webmasters to block content sniffing that was happening and could transform non-executable MIME types into executable MIME types. Since then, other browsers have introduced it, even if their MIME sniffing algorithms were less aggressive.
Site security testers usually expect this header to be set.
X-Content-Type-Options: nosniff
To learn more check this link
Below some packages in suggestion order that implements this header:
An HTTP cookie (web cookie, browser cookie) is a small piece of data that a server sends to the user's web browser, that may store it and send it back together with the next request to the same server. Typically, it's used to know if two requests came from the same browser allowing to keep a user logged-in, for example. It remembers stateful information for the stateless HTTP protocol.
Cookies are mainly used for these three purposes:
*Session management (user logins, shopping carts) *Personalization (user preferences) *Tracking (analyzing user behavior)
Cookies have also been used for general client-side storage. While this use could have been considered legitimate at a time when there was no other way to store data on the client side, it is no longer the case nowadays where web browsers are capable of using various storage APIs. Since cookies are sent along with every request, it can be an additional performance burden (especially for mobile web). New APIs to consider for local storage are the Web storage API (localStorage and sessionStorage) and IndexedDB.
To learn more check this link
Below some packages in suggestion order that implements this header:
- HTTP Public Key Pinning (HPKP)
The Public Key Pinning Extension for HTTP (HPKP) is a security feature that tells a web client to associate a specific cryptographic public key with a certain web server to decrease the risk of MITM attacks with forged certificates.
To ensure the authenticity of a server's public key used in TLS sessions, this public key is wrapped into a X.509 certificate which is usually signed by a certificate authority (CA). Web clients such as browsers trust a lot of these CAs, which can all create certificates for arbitrary domain names. If an attacker is able to compromise a single CA, they can perform MITM attacks on various TLS connections. HPKP can circumvent this threat for the HTTPS protocol by telling the client which public key belongs to a certain web server.
HPKP is a Trust on First Use (TOFU) technique. The first time a web server tells a client via a special HTTP header which public keys belong to it, the client stores this information for a given period of time. When the client visits the server again, it expects at least one certificate in the certificate chain to contain a public key whose fingerprint is already known via HPKP. If the server delivers an unknown public key, the client should present a warning to the user.
To enable this feature for your site, you need to return the Public-Key-Pins HTTP header when your site is accessed over HTTPS:
Public-Key-Pins: pin-sha256="base64=="; max-age=expireTime [; includeSubDomains][; report-uri="reportURI"]
- To learn more check this link*
Below some packages in suggestion order that implements this header: