This was a funny one! After weeks thinking the Chrome team might have messed up, I finally got frustrated and looked for a solution to one of the weirdest problems I had encountered: the DevTool’s console getting cleared unexpectedly.

This post is part of the ”WASEC: Web Application SECurity” series, which is a portion of the content of WASEC, an e-book on web application security I’m currently writing.

Here is a list of all the articles in this series:

1. Web security demystified: WASEC
2. Introduction
3. Understanding the browser
4. Security at the HTTP level
5. HTTP headers to secure your application
6. Hardening HTTP cookies

Imagine being a backend developer who needs to implement sessions in an application: the first thing that comes to your mind is to issue a token to clients and ask them to send this token with their subsequent requests. From there onwards you are going to be able to identify clients based on the token included in their request.

HTTP cookies were born to standardize this sort of mechanism across browsers: they’re nothing more than a way to store data sent by the server and send it along with future requests. The server sends a cookie, which contains small bits of data, the browsers stores it and sends it along with future requests to the same server.

Why would we bother about cookies from a security perspective? Because the data they contain is, more often than not, extremely sensitive — cookies are generally used to store session IDs or access tokens, an attacker’s holy grail. Once they are exposed or compromised, attackers can impersonate users, or escalate their privileges on your application.

Securing cookies is one of the most important aspects when implementing sessions on the web: this chapter will, therefore, give you a better understanding of cookies, how to secure them and what alternatives can be used.

A few weeks ago I bumped into mkcert, a tool written by Filippo, the same guy behind the popular heartbleed test tool.

This goes right into the list of books I really wanted to like but kind of disappointed me.

The book is structured extremely well, so it comes out as a very enjoyable read. One downside, though, becomes fairly evident a few chapters in: it isn’t practical at all, describes few patterns and instead focuses a lot on processes, advices and high-level description of approaches you should follow to embrace CN infrastructure.

This post is part of the ”WASEC: Web Application SECurity” series, which is a portion of the content of WASEC, an e-book on web application security I’m currently writing.

Here is a list of all the articles in this series:

1. Web security demystified: WASEC
2. Introduction
3. Understanding the browser
4. Security at the HTTP level
5. HTTP headers to secure your application
6. Hardening HTTP cookies

As we’ve seen, servers can send HTTP headers to provide the client additional metadata around the response: beside sending the content that the client requested, clients are then allowed to specify how a particular resource should be read, cached or secured.

There’s currently a very large spectrum of security-related headers that we should understand, as they have been implemented by browsers in order to make it harder for attackers to take advantage of vulnerabilities: the next paragraphs try to summarize each and every one of them by explaining how they’re used, what kind of attacks they prevent and a bit of history behind each header.

This post is part of the ”WASEC: Web Application SECurity” series, which is a portion of the content of WASEC, an e-book on web application security I’m currently writing.

Here is a list of all the articles in this series:

1. Web security demystified: WASEC
2. Introduction
3. Understanding the browser
4. Security at the HTTP level
5. HTTP headers to secure your application
6. Hardening HTTP cookies

HTTP is a thing of beauty: a protocol that has survived longer than 20 years without changing as much.

As we’ve seen in the previous article, browsers interact with web applications through the HTTP protocol, and this is the main reason we’re drilling down on the subject. If users would enter their credit card details on a website and an attacker would be able to intercept the data before it reaches the server, we would definitely be in trouble: understanding how HTTP works, how we can secure the communication between clients and servers, and what security-related features the protocol offers is the first step towards improving our security posture.

PSA: book of the year candidate right here.

I never started any of my book reviews with a “book of the year” disclaimer, but this deserves as much of your attention as I can grab: a book that’s so simple, yet so revolutionary, tackling one of the most boring aspects of our life.

I used to think sleep was quite of a useless phase in our lives, there so that we can simply recharge our batteries and go on the following day — and this book managed to radically change my view on the importance of sleep: it’s a scientific take on the process of sleeping, how it impacts and shapes us, giving you a 360 degree overview on the consequences of a chronic lack of sleep.

One of my latest habits is to look for recommendations from high-profile tech influencers, and this came after reading an intriguing post by Seth Godin. Even though the post is from 2006, I thought “why not giving it a shot?” and, boy, I was really pleased with my choice.

The Personal MBA is a condensed business lesson you will not regret: I particularly enjoyed the chapter around accounting and financials, as it helped me understand a few more technical terms and get a high-level overview of the matter. As you might have guessed, the book is not about software, and rightly so; at the same time I would encourage anyone passionate about building products and amazing audiences to give it a shot, as the books sums up a lot of interesting concepts for people who intend to run a business or launch a product.

This post is part of the ”WASEC: Web Application SECurity” series, which is a portion of the content of WASEC, an e-book on web application security I’m currently writing.

Here is a list of all the articles in this series:

1. Web security demystified: WASEC
2. Introduction
3. Understanding the browser
4. Security at the HTTP level
5. HTTP headers to secure your application
6. Hardening HTTP cookies

I want to open this series with an article aimed at understanding what browsers do, and a brief explanation on how they do so. It is important since most of your customers will interact with your web application through a browser, so it’s imperative to understand the basics of these wonderful programs.

This post is part of the ”WASEC: Web Application SECurity” series, which is a portion of the content of WASEC, an e-book on web application security I’m currently writing.

Here is a list of all the articles in this series:

1. Web security demystified: WASEC
2. Introduction
3. Understanding the browser
4. Security at the HTTP level
5. HTTP headers to secure your application
6. Hardening HTTP cookies

WASEC is a series about Web Application SECurity, written in the attempt to summarize security best practices when building web applications.

Today’s web platform allows developers to build magnificent products, with technologies that were unthinkable of just a few years ago, such as web push notifications, geolocation or even “simpler” features such as localStorage.

These additional technologies, though, come at a cost: the spectrum of vulnerabilities is amplified, and there’s more we must know when developing for the web. When iFrames were introduced, everyone was quick to point out how great of an invention they were (at least back in the day), as they allowed to embed content from different webpages very easily; few, though, would have thought that the very same technology would serve as the basis of clickjacking, a type of vulnerability only possible thanks to additional features to the HTML standard.

As Wikipedia puts it:

Clickjacking is possible because [of] seemingly harmless features of HTML web pages

Let me twist the tale and ask you if you were aware that CSRF attacks are about to disappear. How? Thanks to browsers supporting SameSite cookies (discussed further on in the series).

See, the landscape surrounding the web is changing quickly, and having a good understanding of the platform, with a keen eye on security, is the goal of this series: to make sure we’ve raised our security awareness.

WASEC is a series written to demistify web security, and make it easier for the everyday developer to understand important, security-related aspects of this universal platform.