Everything about Client-Side Security

Client-side security is always in the news, most often for the wrong reasons. A lion share of all cyber attacks is targeted client systems and software like email applications, web browsers, and desktop systems.

Bots, viruses, worms and all sorts of malicious content are wriggling their way into naive user systems. In 2016 alone, cybercrime has cost the world approximately $450 Billion (Source: CNBC).

Unfortunately, cybercrime is touted to be drastically increasing in volume and sophistication too. Hackers are becoming intelligent at baiting and hooking users who are ignorant about the perils of remaining browsing unprotected on the web.

Are you a potential target? By a huge margin, YES!

Can you thwart cybercrime? By all means, YES!

What should be done? Read further. And as soon as you are done, implement them. That should do to keep your client-side systems secure on the web.

Ditch HTTP. Embrace HTTPS

We mean it. If you are still running on HTTP, it is time to ditch it.

Think of it. Google is placing HTTPS website at the top of search results. Customers prefer paying to websites that are secure. The green address bar and the padlock symbol has become accepted as tokens of Internet security. HTTP is on its way out.

There is no more time to be wasted with HTTP. Get an SSL certificate and upgrade your website to HTTPS.

“But, SSL Certificates need money to spend. Is it worthwhile?” We have heard this question many times, and each time there is only one answer. It is safer to spend on online protection than to repent on data that is gone forever.

HTTPS helps prevent one of the most common cybersecurity attacks: Man-In-The-Middle.

A Man-In-The-Middle attack works in silent mode. You won’t even know you are being attacked. The hacker positions between your client system and the other end, maybe a server you are communicating with. The “Man” steals all information that is being exchanged.

If you are exchanging something valuable like a bank account credentials, credit card number or personal details, they are as good as gone.

But, with HTTPS that risk is prevented. HTTPS creates a safety tunnel between your client-side system and the server or the browser with whom you are exchanging information.

Next Up, Fix Your Content Security Policy

A Content Security Policy is a security standard that is designed to prevent cross-site scripting (XSS) attacks, clickjacking and similar malicious code injecting cyber attacks.

CSP does a great job of mitigating cyber attack risks, that it is even included in the Candidate Recommendation of the World Wide Web Consortium.

Having a CSP allows you to define what kind of content, scripts, media, etc. can be allowed to run on your website. You can set up a CSP using HTML meta header like this:

1	Content-Security-Policy: policy

The policy can be further customized with additional directives like:

• script-src – sets acceptable sources of JavaScript code
• style-src – defines acceptable origins of CSS styles
• connect-src – specifies the servers the browser can connect to using XHR, WebSockets and EventSource
• font-src – lists allowed sources of fonts
• frame-src – defines what origins should be allowed in iframes
• img-src – sets allowed image sources
• media-src – lists origins that can serve video and audio files
• object-src – same as above but for Flash and other plugins

Setting these directives is a must-have to safeguard your website.  If these directives are not set on your website, it will accept and run all kinds of code origins, which is a huge risk.

Almost every modern web browser like Google Chrome, Mozilla Firefox, Safari, Opera use the standard Content Security Policy HTML header.

Prefer Cross Source Resource Sharing than JSONP

Cross Source Resource Sharing (CORS) is a web mechanism used to fetch resources like fonts, images, stylesheets, etc. from external domains than the initial resource from where it was served. CORS fetches resources only from such resources that are permitted by the same-origin security policy.

A same-origin security policy a web browser allows scripts to run in the first web page only if the second web page also share the same origin. The Same-origin policy ensures that the sources are authentic and not injected with any malicious.

Why is CORS preferred over JSONP? JSONP allows resources to be fetched from other servers even if they have a same-origin security policy. Now, this poses a huge security risk since it lets the door open for hackers to inject malicious code when the resource callback happens.

CORS removes the risk by ensuring that the web elements are indeed from a same-origin source. All web browsers except Opera Mini allows the running of CORS. The only glitch though is that CORS support needs to be provided by service providers. It is not something that the developer can get done on his own.

Conclusion

Fixing client-side applications is easily said than done. You cannot ignore them either. A sizeable portion of cyberattacks begins from the client side. By client side, we mean not just a single system of a network. It could be anything, like a software, an email application, etc.

Every single client-side application has the risk of being hijacked and taken over by hackers with the aim to steal data and confidential user information. The best way to prevent such security threats is by implementing security measures that are tailor-made for client-side security.

We have three major client-side security measures until now. There are still more, but these will do to fix your cybersecurity woes for now. Begin with migrating to HTTPS. It will ensure that all your transactions are encrypted and free from the risk of interception.

Next, set up a decent Content Security Policy that will prevent the possibility of malicious code injections. Follow it up with using Cross Source Resource Sharing to ensure that only trustworthy scripts from genuine origins are allowed to run on your website.

All done and dusted, rest assured that your website will remain hack-proof for a very long time to come.