Something I’m extremely fascinated with is the power of simplicity: I’ve found myself fighting complexity far too many times, and always realized that when planning and developing a system, we’d achieve the best results when keeping things simple.

What’s more interesting, simple systems could be combined together to kind of form more structured organizations that would still benefit from their straightforward pillars.

Naturally, my curiosity evolved over time and I wasn’t keen on confining to the tech field — so once I saw this book, I thought I’d like to see if businesses have similar tendencies to the systems we build with code.

The idea behind equal web performance is that you should stop looking at metrics other than the 99th percentile: resources shoud be “equally” distributed across all of your clients so that a few clients don’t act as a bottleneck for the others.

Last week I was working on an application that has an idempotent API, meaning the same request can come in multiple times without generating errors or side effects: the request can be safely replayed, as it won’t affect the state of the server.

Since I was using MySQL as a storage engine behind this API, INSERT IGNORE was my first thought.

What a tragic mistake.

A few weeks ago I got to the office and noticed something peculiar: my XPS’ battery had around 7 remaining hours of life, while until the week earlier I had never seen it above 3 hours.

This is the (very short) story of how I supercharged my laptop’s battery without even knowing how to.

A few days ago I wanted to integrate gravatar in one of the applications I’v been working on, and realized gravatar still uses MD5 for hashing the user’s email.

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.