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.
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 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.
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
*, 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.
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.