Front End Security is a thing, and you should be concerned about it

Tweetdeck had a pretty bad day recently. To make a long story short, a Cross-Site Scripting (XSS) vulnerability was found in the popular web app, and it was exploited by nearly everyone who knew how to write JavaScript. It’s unknown how much, or if any at all, damage was caused by this vulnerability, but this tweet highlights how many Tweetdeck users can be effected by one overlooked detail.

Tweetdeck quickly shut down its service while it implemented a fix, but the damage had already been done. A failure to pay attention to security on the front end cost them downtime, lost users, and potentially ad revenue.

In case it hasn’t been made clear already, front end security is an important issue. A front end vulnerability happens when someone is able to harm your website, application, or users, without ever having to gain access to a server, database, or hosting provider.

Twitter, Facebook, and GMail have all been vulnerable to these kinds of attacks. As a web developer, the security of your site or app should be a top concern, especially as those sites and applications become popular. Lets take a look at some common front end vulnerabilities, as well as ways to safeguard against them.


Client XSS

On the front end, a Cross-Site Scripting vulnerability happens when dynamic data is sent to a user without being validated for malicious content. In the case of tweet deck, the dynamic data was the tweet, and the malicious content was the executable JavaScript code being tweeted.

Most often, XSS vulnerabilities occur when websites or applications don’t remove executable code from input fields that their users have access to. For example, a web developer working on a photo sharing application must ensure that only images can be uploaded in the required fields, and that those image fields will remove broken links, incorrect file extensions, and malicious code.

How do you protect against XSS? Start by using frameworks and services that have built in protection against these kinds of attacks. Learn more about protecting against XSS here.

Iframes

Iframes have been around for quite some time, and have several different use cases. They can also cause a lot of trouble. It’s important to remember that displaying content inside of an Iframe means you’re trusting that content not to be vulnerable or malicious. Iframes and XSS attacks usually go hand in hand, meaning that malicious content inside of an Iframe can go on to effect your users. If the content inside of the Iframe is coming from your domain, its important to make sure that the Iframed content is secure and not vulnerable to an attack.

Luckily theres a great way to protect against these vulnerabilities using the sandbox attribute. It’s also important to make sure that sensitive pages in your site or application don’t allow for use inside of an Iframe. This can be achieved using the X-Frame-Options http response header.

CORS

If you’ve ever wanted to share resources across subdomains, you’ve most likely had to deal with Cross-Origin resource sharing. When CORS is used irresponsibly, it can allow anyone to send a request to your server, potentially revealing sensitive information in the response. If you’ve ever set Access-Control-Allow-Origin to *, its worth making sure that you haven’t compromised your site. Google has a comprehensive overview on CORS security which is well worth the read.

Cookies

Libraries like jQuery Cookie make it very easy to set cookies without having to rely on a server. When working with cookies, it is important to remember that they can be vulnerable to XSS and CORS exploits. Their also not encrypted by default, which means a password stored in a cookie over http will be stored in plain text. Be sure to check out this tutorial by Treehouse which provides a list of ways to make your cookies more secure.

Front End Security and HTML5

HTML5 elements and API’s have been known to contain security vulnerabilities every so often. Although browsers are quick to implement fixes, it’s always a good idea to keep this in mind when working with sensitive content. html5sec.org provides an overview of vulnerabilities in HTML5 elements, along with the browser versions that are vulnerable to them.


Hopefully you’ve been inspired to take a second look at your online content to ensure that it’s free of dangerous security vulnerabilities. Many of these threats can be eliminated by using properly built frameworks and services, instead of building from scratch. More importantly, take some time to properly test the code that you write. The extra time it takes to test and review your front end code will always lead to better, more secure, websites and applications.

Tim Evko

I'm a front end web developer from New York, with a passion for responsive web development, Sass, and JavaScript. I live on coffee, CodePen demos and flannel shirts. I can also be found on Twitter - @tevko.

1 Comment

This post currently has one response. What do you think?

You can use basic HTML when posting code, please turn all < characters into &lt; or > into &gt;
If the code is multi-line, use <pre><code></code></pre>

Leave a Reply

Your email address will not be published. Required fields are marked *

Current ye@r *