17 articles, 1 books. Go to books ↓

This is intended as a simple abbreviated cheat sheet for securing JavaScript based single page web apps. It's not meant to cover everything in depth, but rather point you in the correct directions with resources.

A well-designed application has to have a good balance of various components: aesthetics, usability, security, and so on. Most web apps have measures employed to protect sensitive data, and a majority of those measures are related to information submission and account credentials. That said, this is one area where security and design decisions can easily clash with each other.

This tutorial highlights one promising new defense that can significantly reduce the risk and impact of XSS attacks in modern browsers: Content Security Policy (CSP).

The world of SSL/TLS Internet encryption is in trouble again. You may have heard that recently a new vulnerability called POODLE has been found in the ancient SSLv3 protocol. Shortly before another vulnerability that's called BERserk has been found (which hasn't received the attention it deserved because it was published on the same day as Shellshock). I think it is crucial to understand what led to these vulnerabilities.

Browser JavaScript has earned a bad reputation for security vulnerabilities, so we need to keep our Node.js apps as secure as possible!

Web authentication systems have evolved over the past ten years to counter a growing variety of threats. This post will present a fictional arms race between a web application developer and an attacker, showing how different threats can be countered with the latest security technologies.

In this infographic we look at the five stages of a Web App Attack from a Hacker’s perspective.

As much as we like to keep pushing the needle further around the "strong security dial" with things like security headers, strong HTTPS implementations and robust hashing algorithms, every now and then we need to take a moment to remember just how low the bar still remains and that frequently, we can't even get the basics right.

This is exactly what it looks like: enter a username - any username - and the site will give you the email address. John, Mary... troyhunt all resulted in an email address being publicly shown. This doesn't happen by accident; this is something that someone decides is a "feature".

Let's say we have a client that can initiate a network request for any URL on the web but the response is opaque and cannot be inspected. What could we learn about the client or the response? As it turns out, armed with a bit of patience and rudimentary statistics, "a lot".

Delegating responsibility to others which in effect gives them control to run script on your website is understandably concerning, particularly for certain classes of web asset. But there's a way that lets you have your public CDN cake and eat it too, and that's subresource integrity, here forth referred to as SRI.

With the October 2017 deadline approaching for compliance with Chrome's Certificate Transparency policy, sites can use the new Expect-CT header to determine if they're ready. It's easy to deploy and has a "report-only" mode so there's no risk involved. Here are the details.

Developing secure, robust web applications in the cloud is hard, very hard. If you think it is easy, you are either a higher form of life or you have a painful awakening ahead of you.

It's always a challenge to keep up with this growth and always know what app does, why and when, and what needs extra security measures on your part. This kind of a holistic analysis of security is known as threat modeling. There are different methods or even tools for doing that.

It could be possible for any website to access this data. This vulnerability is called JSON hijacking, and allows websites to extract the JSON data from those API's.

As the web evolved, so too did the knowledge of its inherent security vulnerabilities. Clever tricks that were played on one site could be copied on literally hundreds of other sites. It was a normal sight to log in to a website to find nothing working because someone had breached its defences and deleted its database. Lessons in web security in those days were hard-earned. What follows are examples of critical mistakes that brought down several early websites, and how you can help protect yourself and your team from the same fate.

This post discusses web security issues that I come across – so far thankfully mostly by reading about them. It is a work in progress which I’ll keep updating. The post title includes “advanced” because the topics discussed here involve clever, non-trivial hacks, are novel at the time of their publication and often combine features with non-obvious consequences.