Application Hardening

Every place in an app where a habit, not a single fix, is what keeps it safe: what it accepts, what it’s built from, how it’s configured, and what it writes down about itself.

Before you start. The last lesson forced every connection to the app onto an encrypted, verified line, so nobody between you and it can read or tamper with a request in flight (Transport & Network Security). This lesson is about everything that line doesn’t touch: what the app does once a request lands, what it’s built out of, and what it exposes about itself.

The idea in 30 seconds

Hardening is not one fix - it’s the same short checklist run on every part of an app, every time, so a hole that already has a public fix is never the one an attacker gets to use.
An allowlist accepts only the shapes you already know are safe, instead of trying to list every bad one - a list of bad things is never finished.
A CVE is a public id for one known, described hole in one piece of software, so a team can check whether they’re carrying it.
Most of an app is code other people wrote; a scan that checks it against the public CVE list has to run automatically, because nobody can review all of it by hand.
A setting like Content-Security-Policy can tell a browser to refuse to run a script that shouldn’t be on the page at all, even after it’s already been slipped in.
Secrets belong in a locked store, never in a log or a config file, because both get read by more people than the team that wrote them.

Read the story · Skip to the numbers