Recap
In Part 3 every change went through build, static test, dev deploy and a clean deploy, and the clean deploy caught a bug nothing else did.
By this point the product worked and had been tested by its own builders. That’s exactly when you need somebody else to look at it. People who wrote the code are the worst people to audit it, because they know what it is supposed to do and read it that way.
So we conducted an independent audit of the code as it stood, and then did something that matters just as much: we treated its findings as proposals, not orders.
What the audit said
The headline was reassuring. The reviewer described the project as unusually disciplined and said nothing in it was broken. It then offered five areas for improvement, which fell into a few families:
- Dependence on server configuration. Several protections relied on the host honouring a particular configuration file. If a host ignored it, private folders could be exposed.
- Login hardening. The password handling and login throttling could be stronger.
- Constraining paths. Where the admin could supply file paths, those should be limited.
- Speed. Batch processing could be roughly twice as fast with a few changes.
- The public page. Caching, paging and keyboard access could be improved.
There was also a list of smaller things, from a lazy-loading detail to log housekeeping.
How we decided
Each recommendation went into the improvements plan and got the same treatment as any other idea: include, reject, or reshape.
Most were accepted. The configuration worry produced the single biggest change: the app now checks itself. A built-in Security Self-Test confirms that private folders really are blocked, repairs the protective files if they’re missing, and gives the database a randomised filename, so even a host that ignores the protections isn’t leaving it at a guessable address.
Login handling changed too. Passwords are now stored hashed, with a forced password setup on first login, and the admin password must be at least ten characters. Failed logins are throttled per visitor, and the throttle tidies up after itself after a successful login. Admin-supplied paths are no longer editable from the browser at all; they live in the configuration file, where only someone with server access can change them.
On speed, the changes were to decode each image once instead of repeatedly, and to wrap database writes in a transaction. Batches got faster, so the batch size was raised.
On the public page, images are served with long cache lifetimes, large galleries load in chunks as you scroll, and the lightbox can be driven from the keyboard.
Some recommendations were reshaped. The bigger-thumbnails idea, as we saw in Part 2, was rejected because it hurts the first load on phones. The suggestion to add a landing page was met with our deliberately minimal starter-album approach.
Why this is worth doing
An audit isn’t a verdict; it’s a second pair of eyes with different assumptions. Some of its value was in the findings we accepted. Some was in forcing us to articulate why we declined others. Both leave a clearer product.
It also worked because the audit came before the release candidate, not after. Fixing a self-test gap is a small job before release and a worrying one after.
One more benefit is easy to miss. Because every finding went through the same plan, the audit didn’t derail anything. It was simply more input to the process we already had, rather than a crisis to be managed.
In short
The audit found the product sound and made five groups of recommendations. We accepted most, reshaped some and rejected one, and the biggest result was a product that checks its own security.
Read next: Release candidate to production.
Leave a Reply