Shed-light On Client-side Security

Source: Flickr

The security is always related to the server side, maybe that’s right. But we can also add some additional security to our code enhancing the client-side security.

There are many ways that may allow the hacker to hack your server or your website’s client. Many of those ways should be handled by the backend-side. But there’s some security needed at the client-side.

In the next few lines I will give you an overview about some of the ways that’s the hacker can use them to hack your website. And the solution for those ways by a simple way.

So let’s start:

The SQL Injections attack:
While this is more server side vulnerability. But we can ensure that the server doesn’t trust input from the client side blindly. Especially the SQL queries.

SELECT `password` FROM `users`WHERE `id` = 1;

This will return the admin password in most cases.

Injections, revisited:
This type of attack come from the user generated content, the user can write a malicious JS code and let it render on your app’s users.
EX: If user has comment with this code bellow:

<script src=”http://sitename.ex/malicious.js” type=”text/javascript”/>

Which will load and execute the malicious.js when the page loads.

Fortunately, there are two ways to secure those two type specifically on the client side:

1- The first one is to filter the inputs before submission. And make sure that’s it’s not contain a malicious code or SQL code.

2- The second way is to define the Content Security Policy at the header of your application: This CSP allow us to define the origin of all scripting, styling, Images, in our site. Also it can stop execute the inline scripts, styling which will come within the injections, revisited type of injections attack.
That will define by adding a meta tag with a http-equiv attribute like:

<meta http-equiv=”Content-Security-Policy” content=”default-src https://sitename.ex; child-src ‘none’; “>

This code above will block the inline-script and the all other content that needs to be loaded from another URL ( In this example: sitename.ex ).
And all the child URLs will be blocked too.

The iframe security issue:
When you face a need to add a content to your website from another website. You actually give this website’s hacker the all authority to hack your site too. But we can solve this issue by adding the sandbox attribute for the iframe tag. Which block the form submission, script execution, disable APIs… etc. and will not allow to the iframe content to affect on the client browser.

To sum up, this’s only an overview on the client-side security. As clarified above, the security in the client-side isn’t less important than the back-end security. So that makes us -front-end developers- take care of our code security and don’t stand on shoulders of the back-end developers.