Rough note, still forming.
Working through security labs, the pattern that shows up most is not a clever exploit. It is a default nobody revisited: a directory listing left on, an admin path still reachable, a permissive header no one set deliberately, a credential that shipped with the software.
What strikes me is that in almost none of these cases did someone decide to be insecure. They just did not make a decision, and the default made one for them.
The question I try to ask now
When setting anything up: what does this do out of the box, and is that what I want?
It catches a category of problem you cannot find by reading your own code, because the problem is not in your code.
Where I want to take this
I would like to turn this into an actual checklist for a small static deploy: headers, caching, what the host exposes by default. Not written yet. Related: validate on the server.
All lab practice happens inside authorised training environments. Scope first, permission always.
When setting up anything new, read what it does by default before changing anything. The default is a decision somebody already made for you.
Comments
Comments run on GitHub Discussions through giscus, so there is no database here and no account details for me to hold.
To switch it on: make the repo public, enable Discussions, install the giscus app, then set
giscus.repoinsrc/lib/site.ts. Until then this page makes no third-party request.