HTTP Security Headers and Precautionary Measures for Websites

What are Security Headers?

HTTP security headers are a fundamental part of website security. After traveling to any website inside the browser, the browser sends a few request headers to the server, and additionally, the server responds with HTTP reaction headers. These headers are hired via the purchaser and server to proportion data as part of the HTTP protocol. Browsers have described the conduct of the website as consistent with those headers for the duration of the conversation with the server. These headers are, in particular, a mixture of key-value pairs separated by way of means of a colon.

Security headers are used by web applications to configure security in web browsers which makes it difficult to exploit client-side vulnerabilities such as Cross-Site Scripting or Clickjacking in the web browsers.

These three security headers are majorly used for securing web applications.

Enforced security headers
Unsupported security headers
Customizable security headers

Why are HTTP Security Headers necessary?

As we know, too many statistics breaches have been happening in recent times. Many websites are hacked because of misconfiguration or loss of safety. These safety headers will defend our internet site from a few not unusual place assaults like XSS, code injection, clickjacking, etc. Additionally, those headers boost our internet site search engine marketing score.

A way of protecting the websites and web application from being hacked or any unauthorized access, done by creating an extra layer of a protection. Click to explore about, Website Security - Benefits | Tools | Measures

What are the types of XSS Attack and their Prevention?

There are three types of XSS Attacks:

Persistent (Stored) XSS
Reflected XSS
DOM-based XSS

The 3 types of XSS Attacks are described below with their prevention

What is Persistent (Stored) XSS?

Persistent XSS is feasible when a web app takes user input and stores it in its servers. When the equipment doesn’t carry out right front-end and back-end validations earlier than storing the data, it exposes critical vulnerabilities.

Example: Within the comment when an attacker identifies vulnerabilities functionality under a post on any social networking site. The vulnerability is that the social community renders the raw input from the feedback in the HTML on the page. When any social networking site uploads these comments, it'll include the `script` tag in its HTML. This kind of practice will redirect the current user to the URL of the malicious website and might send all of the cookies as an issue parameter. The hostile website can then reserve the cookies and steal sensitive data.

Prevention for Persistent XSS

To prevent Persistent XSS attacks, proper sanitization of all user input is done before being stored on the servers.

What is Reflected XSS?

Reflected XSS attacks use input parameters for damaging script content material withinside the HTTP request, which can be manipulated without any trouble. The malicious script is then contemplated from the server in an HTTP response and gets executed withinside the sufferer’s browser.

Let’s take an instance of a domain named examples.com/profile containing a name parameter. The URL for the request might appear like this: https://examples.com/profile?user=Tom. Based on the input, the web application would thus respond with “Hi Tom” at the top of the page. If the specifications are not authenticated to ensure it only contains expected data, an attacker could have a user visit a spiteful version.

When the response is despatched to the browser, it consists of that malicious script, which is then performed withinside the browser, probably without the user’s knowledge. This is a reflected XSS attack because the malicious code is immediately “reflected” back to the consumer making the request.

Prevention for Reflected XSS Attack

Customers can keep away from Reflected XSS attack attacks by being vigilant.

What is DOM-based XSS?

For the DOM-based XSS to take place, the JavaScript code of the web app takes input from a source that is controllable by the attacker, such as the URL in the browser’s tab.

Example: Let’s say the application uses the query parameter “name” to instantly display the user’s name on the screen while being on standby for the rest of a page to load. This can yield the same result as with a reflected attack if it’s not properly validated, then the hacker successfully makes the victim open a suspicious link.

Prevention for DOM-based XSS Attack

Developers should implement data validation and avoid displaying raw user input, despite the presence or absence of communication with the server.

Cyber threats have become more complex and complicated. Many companies meet stealthy attacks in their systems. Click to explore about, Advanced Threat Analytics and Intelligence

Precautionary measures for Security Headers in JS(XSS Attacks)

The Precautionary measures for Security Headers in JS(XSS Attacks) are listed below:

Cross-Site Scripting Protection (X-XSS)

X-XSS header enables defending websites from script injection attacks. When an attacker injects malicious JavaScript code into an HTTP request for access to private data, including consultation cookies, the HTTP X-XSS-Protection header can forestall the browsers from loading such internet pages every time any hit upon is contemplated cross-web web page scripting (XSS) assaults. XSS is a completely not unusual place and a powerful attack.

Syntax for Cross-Site Scripting Protection

X-XXX-Protection: 0
X-XXX-Protection: 1
X-XXX-Protection: 1 ; Model=block
X-XXX-Protection: 1 ; report=<reporting-uri>

Website IFrame Protection (X-Frame Options)

The X-Frame-Options HTTP reaction header may be used to coach the browser on whether or not an internet web page ought to be allowed to render a <frame>, <iframe>, <embed> or <object> or detail on an internet site or not. This header protects customers from ClickJacking assaults. An attacker uses a couple of hints to trick the consumer into clicking something specific than what they suppose they’re clicking.

Syntax

X-Frame-Options: DENY
X-Frame-Options: SAMEORIGIN

Preventing Content-Type Sniffing

X-Content-Type-Options reaction header protects the browser from MIME-sniffing a reaction away from the declared content material-kind. A MIME-sniffing vulnerability permits an attacker to inject a malicious resource, like a malicious executable script. Suppose an attacker modifies the reaction for a harmless resource, like a picture. With MIME sniffing, the browser will forget about the declared photograph content material kind, and rather than rendering a photograph, will execute the malicious script.

Example: A Chrome purchaser makes a request to an internet server for an asset (e.g., photograph.jpg). The browser then accepts the MIME kind described via the starting place server and shows the asset to the viewer. A reaction is dispatched lower back with the header X-Content-Type-Options: nosniff. This prevents the purchaser from "sniffing" the asset to decide if the document kind is something apart from what is said by means of the server.

Syntax

X-Content-Type-Options; nosniff

Managed Security Services provide the industry-leading tools, technology and experience to assist secure your data assets round the clock. Click to explore about, Managed Security Services? - Secure Data Assets

Content Security Policy(CSP)

Content-Security-Policy header is employed to instruct the browser to load only the allowed content defined within the policy. The whitelisting approach has been followed according to which the browser will choose from where it has to upload the pictures, scripts, CSS, applets, etc. This policy prevents the exploitation of Cross-Site Scripting (XSS), ClickJacking, and HTML injection attacks if appropriately implemented.

Using CSP, Data sources allowed by a web application can be limited by defining the appropriate CSP directive in the HTTP response header.

Why to use: Whitelisting approach has been followed according to which the browser will choose from where it has to upload the pictures, scripts, CSS, applets, etc. If appropriately implemented, this policy prevents the exploitation of Cross-Site Scripting (XSS), ClickJacking, and HTML injection attacks.

Usage of Content Security Policy

Nonce Based CSP: A nonce is a random number that is used only once. A non-based CSP is only secure if we pass different nonce values for each response.
So, set the headers on the server configuration file as:-

Content-Security-Policy:
script-src 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline';
object-src 'none';
base-uri 'none';

In index.html we need to embed as:

<script nonce="{RANDOM1}" src="https://example.com/script1.js"></script>
<script nonce="{RANDOM1}">
// Inline scripts can be used with the `nonce` attribute.
securityFunction()
</script>

E.g., Google photos use a nonce-based CSP method to secure.

Hash-based strict CSP: If our application needs to be served statically or cached like building single-page applications, then hash-based CSP should be used. The configuration file looks like this:

Content-Security-Policy:
script-src 'sha256-{HASH1}' 'sha256-{HASH2}' 'strict-dynamic' https: 'unsafe-inline';
object-src 'none';
base-uri 'none';

CSP Evaluator tool and can be read more about on CSP documentation and CSP headers.

The Cross-Origin Resource Policy

The attacker can embed resources from another origin, such as our site, to learn about them by exploiting web-based cross-site leaks. It can be reduced by using the CORP policy. As it defines the set of websites, it can be loaded by headers to choose amongst these values: same-site,same-origin, and cross-origin. Resources are supposed to send this header to indicate whether other websites allow loading of the latter.

Usage of Cross-Origin Resource Policy

It is recommended that all resources are served with one of the following three headers.

Cross-origin:

It should be used when it is required to load the data from different websites.

Same-Origin:

We should apply this to resources that include sensitive information about the user or responses of an API intended to be called only from the same origin.

Same-Site:

It should be used when it is intended to be loaded by other subdomains of our site.

Playground:- CORP-Demo.
Difference between cross-origin, same-origin.

Our solutions cater to diverse industries with a focus on serving ever-changing marketing needs. Click here for our Cyber Security Services and Solutions

Cross-Origin Resource Sharing(CORS)

It follows a header-based mechanism that permits a server to point to any other origins (scheme, domain, or port) than its own, from which a browser should permit the loading of resources.

Usage: Depending on request details, a request will be classified as a simple request or a preflight request.

Criteria for a simple request:

The approach is GET, HEAD, or POST.
The custom headers only include Accept-Language, Accept, Content-Language, and Content-Type.
The Content-Type is application/x-www-form-urlencoded, multipart/form-data, or text/plain.

So, when the browser sends a request with the Access-Control-Allow-Origin:*, the origin may utilize the useful resource. If we need to limit the server to be accessed most effectively through sure origins, it may be described in this parameter.

Preflight Request: In the preflight requests the browser sends an HTTP request using the options method to the resources on the other origin to determine if the actual request is safe to send.

Usage:

const xhr = new XMLHttpRequest();
xhr.open('POST', 'https://bar.other/resources/post-here/');
xhr.setRequestHeader('X-PINGOTHER', 'pingpong');
xhr.setRequestHeader('Content-Type', 'application/xml');
xhr.onreadystatechange = handler;
xhr.send('<person><name>Arun</name></person>');

Cross-Origin Embedder Policy(COEP)

(COEP) response header prevents a file from loading any cross-origin resources that do not supply explicitly grant the document permission

Usage:

Cross-Origin-Embedder-Policy: unsafe-none | require-corp

Unsafe-none: This is the default value. Allows the file to fetch cross-origin resources without giving specific permission via the CORS protocol

Require-corp: A document can only load resources from the equivalent origin or resources explicitly marked as loadable from another origin.

PlayAround: Check Security headers

Conclusion

HTTP headers are the fundamental component of the internet site. It helps to make the balance between security and usability, developers implement functionality through the headers that make applications secure and versatile.