Cyber security has become a necessity for any web developer building client-facing web applications. We are looking into few options for securing our app.

Why cyber-security?

Cyber security has become a necessity for any web developer building client-facing web applications.

We are looking into following options for securing our app:

  • Disable Caching Confidential Resources
  • Enable XSS Filtering
  • Controlling Framing
  • Whitelisting Sources

HTTP headers are an area we can address for starters.

What are HTTP Headers?

HTTP request and HTTP response messages consist of clear text fields in the header. These are called HTTP Headers.

These headers are used by the HTTP client and server to:

  • Send & receive metadata about the connection to be established
  • The resources being requested
  • And the returned resource itself

Disable Caching Confidential Resources

Always caching HTTP GET* requests, enables HTTP to enhance performance, and reduce network traffic.

But this can also expose end users to be vulnerable for personal information theft.

There are three headers you can send to teh client to make sure the cache will be disabled:

  • CacheControl
  • Expires
  • Pragma

Cache Control

This header can be used to instruct clients and intermediate proxies on how to respond to caching.

  • no-cache – Do not to use a previously cached response
  • no-store – Do not store the response
  • must-revalidate – if the response is somehow cached, the cache must be revalidated on the origin server

Pragma: no-cache

Some HTTP clients like intermediary proxies, still might not fully support HTTP 1.1 and may have trouble handling the Cache-Control header mentioned above.

For backwards-compatibility with HTTP 1.0, you will want to include this header as well.

Pragma: no-cache

Disabling cache will slow down the performance so make sure to disable caching only for confidential resources.

You can write your header with above considerations as shown below:

Rails 4:

response.headers['Cache-Control'] = 'no-cache, no-store, max-age=0, must-revalidate'
response.headers['Expires'] = '-1';
response.headers['Pragma'] = 'no-cache'


function requestHandler(req, res) {
    res.setHeader('Cache-Control', 'no-cache, no-store, max-age=0, must-revalidate');
  res.setHeader('Expires', '-1');
    res.setHeader('Pragma', 'no-cache');

Enable XSS Filtering

Cross-site scripting attack or reflected XSS, is a malicious attack on a web application by injecting JavaScript code into an HTTP request and accessing confidential information like session cookies.

Most browsers today, employ a XSS filters to mitigate cross-site scripting attacks but may fail to detect a real XSS attack.

But fortunately a web application can override this configuration via an X-XSS-Protection header.

function requestHandler(req, res) {

1 or 0 enables or disables the filter.

mode=block will block the page from rendering when an attack is detected.


An insecure connection exposes the user to multitude of attacks, which could easily lead to cookie theft or even worse. For an example, A malicious attacker can easily spoof network frames within a public Wi-Fi network and to obtain session cookies of users who are not using HTTPS.

Man-in-the-Middle (MitM) attacks

A downgrade attack, which an attempt to force the connection to be downgraded to an insecure connection, thus exposing the user to MitM attacks.

In order to enforce the usage of HTTPS, we can use the HTTP Strict Transport Security (HSTS) header. Put simply, HSTS makes sure all communications with the origin host are using HTTPS.

HSTS directives can be configured like the following:

  • includeSubDomains – HSTS will be applied to all sub domains
  • max-age= – browser will cache this header for a given time
  • preload – forces browsers to always load your web app securely by hardcoding a list of HSTS preload-enabled domains into the browser’s code

If you are using preload directives, you will have to make sure that your website can only be using HTTPS.

Avoiding Content-Type Sniffing(MIME Sniffing)

This feature enables the browser to detect the type of a resource provided as part of an HTTP response by sniffing the actual resource bits, regardless of the resource type declared through the Content-Type response header. While this feature is indeed useful in some cases, it introduces a vulnerability and an attack vector known as a MIME confusion attack.

We can use X-Content-Type-Options header to address this issue.

X-Content-Type-Options: nosniff

Controlling Framing

Using iframes in your website can makes clickjacking easier.


An attack that tricks the user into clicking something different than what they think they’re clicking.

By using X-Frame-Options you can block this attack by restricting your web app from being framed.

X-Frame-Options: SAMEORIGIN

Whitelisting Sources

Content Security Policy (CSP) enables developers to whitelist trusted sources and operations.

Content Security Policy (CSP)

CSP is a W3C specification that defines a powerful browser-based security mechanism, enabling granular control over resource-loading and script execution in a web app.