All types of websites and web apps, ranging from single page websites to large multifaceted web apps, are vulnerable to cyber-attacks.
In 2016 alone, around 40% of security breaches on data primarily happened with web apps, and this is why web app developers need to consider security issues so seriously.
One of the most vulnerable areas for web app security is the HTTP headers. HTTP response headers have been embraced widely by web developers to address such security issues.
The basics of HTTP headers
Technically speaking, HTTP headers just refer to simple fields that remain encoded in simple text and make a part of the HTTP request and response header message. These header messages allow both client and servers to send and receive metadata concerning the establishment of the connection and about making resources accessible.
The web apps largely work smoothly allowing access to contents to clients and client requests to servers through these header messages.
Caching disabled for some links holding confidential resources
Caching allows access to a web page easily when opened for the second time, but for certain web pages that have confidential resources, caching can actually cause a lot of security risks. Most security experts feel that when your resources are very critical and confidential for your business, it is advisable not to allow caching.
When you disable caching of confidential pages, the shared network of devices and computers cannot access the page without going through the statutory process of authentication and identification.
This approach is embraced by many banking and financial web apps and websites to prevent leakage of confidential data. When a cache is disabled by pressing the back button, one cannot access the information typed in the form fields of the previous page.
Moreover, if a network connection is disrupted while accessing the web page and gets restored within a few minutes, the page will expire automatically thanks to disabled caching.
Taking control of the Framing
Sometimes a small web app is sheltered within another bigger or parental web app: this is permitted by iframe which is basically an HTML inline frame. However the modern web cannot do away with such uses as there are many embedded third-party apps used by vast majority of web apps these days.
In spite of their important role, such a small app nestled within a bigger app actually makes a lot of problems for the latter. It undermines the SEO potential as it makes the job of crawler engine tougher and interferes with the ease of browser navigation.
The biggest threat perpetrated by iframes is a thing called clickjacking. Clickjacking refers to a kind of cyber-attack that is responsible for forcing user clicking something else instead of the thing they intended to click on. To prevent such attack, you need to exercise total control over framing links.
The most effective and straightforward way out of this type of attack is to completely avoid framing links within. When you want to allow a few specific domains to access your website as their residing place, you can make use of the ALLOW-FROM directive to ensure limited access to iframing for some web domains.
Using the SAMEORIGIN directive for frames is also effective as this only allows iframes to be used for apps of the same domain while offering optimum security for links.
Clearly whitelisting some source
You can always optimize the security of a web app just by making use of the XSS filter of the browser, but the problem is there are browsers that do not support this feature. For example, Mozilla Firefox doesn't offer XSS filter and instead offers pattern-matching which can be easily broken.
Naturally, for all browsers you cannot depend on XSS filtering but for all browsers you can ensure security with an additional cover by whitelisting all the trusted web links. The Content Security Policy (CSP) is a protocol through which app developers can whitelist trusted web links and is loaded with all the W3C specification concerning web security and helps you differentiate the reliable resources from the vulnerable ones.
Not using Content-Type Sniffing
Finally, for a seamless and smooth web user experience, most advanced and sophisticated browsers now come with a feature referred as content-type sniffing. Thanks to this feature, the browser becomes able to detect beforehand the kind of resource delivered through an HTTP response.
This is done by a “sniffing” action that gets the idea of the resources made available by the response. It is certainly a great feature that gives our web user experience a lot of smoothness.
On the other hand, the feature also makes web security tremendously vulnerable at times. For example, a malicious program can present an innocent image for sniffing and can render a malicious program while rendering finally.
There is a great solution to this threat. The X-Content-Type-Options response header introduced with Internet Explorer 8 in 2008 has become part of most modern browsers, and now helps block any third party script while allowing sniffing for regular contents.
The above approaches are the result of the constant combat of web developers with equally pervasive and cunning cyber-attacks. Today, just by tweaking a few aspects of the HTTP headers you can enjoy almost near perfect security for your web app.
Keval Padia is a co-founder of Nimblechapps, a prominent mobile app development company based in India. He follows different tech blogs and current updates of the field lure him to express his views and thoughts on certain topics.