Most exposures are not break-ins. They are a key left in a page, a table whose access control was never switched on, or a policy that matches nothing while looking like it works.
What this covers
- Access control audit. What an anonymous browser can actually retrieve — established by retrieving it, not by reading the configuration.
- Application hardening. Security headers that permit exactly what they were added to prevent are the norm. The work is removing what forces the loophole open rather than documenting why it has to stay.
- Reliability review. A form that emails and reports success only if the email worked will silently destroy enquiries the day a credential expires. The durable write goes in front of the notification.
- Delivery and configuration audit. Redirect rules that never run. A sitemap every tool calls fine and no parser accepts. Assets cached for a year against markup that changed yesterday. These pass every check, return no error, and stay broken for months.
- Measurement audit. Whether pages are tagged twice, whether one property is fed by several sites, whether staging traffic is counted as real.
- Refactor verification. For a large mechanical change, "the diff looks equivalent" is not evidence. Old and new are measured side by side and what actually renders is compared.
How it is done
By probing the live system rather than reading the config, because the whole category is faults that configuration review cannot see. Findings come with the reproduction, not just the claim.
See it in detail
This work is written up at length, including the errors found in the author's own sites, in the long-form write-up.
Who this is for
Anyone who has shipped something publicly and has not since checked what it actually serves, as opposed to what it was configured to serve. Particularly relevant where a form collects anything, where a database is reachable from a browser, or where a redirect or header rule is doing security work.
It is not a penetration test and does not pretend to be. It is an audit of the category of fault that returns no error, which is a different exercise and finds different things.
What we would look at first
- What an anonymous request actually gets back. Established by making the request, at more than one casing and encoding, rather than by reading the rule that is supposed to stop it.
- Whether a rule that looks active matches anything. A policy matching zero rows and a policy correctly permitting nothing are identical from the outside, and only one of them is doing its job.
- What a failing path does. Specifically whether a notification failure can destroy the thing it was notifying about, which is the most common quiet data-loss shape in a small application.
- Whether measurement is telling the truth — pages tagged twice, one property fed by several sites, staging counted as real traffic.
What determines the cost
How many surfaces are public, and how many distinct rule systems sit in front of them — a redirect file, a header file and an edge function disagreeing with each other is three times the work of any one of them. Whether there is a written statement of what access is supposed to be, because an audit with no declared intent can only report what is, not what is wrong. And whether findings need reproductions attached, which they do here by default.
Proof
The config was mine and the fix on paper was still wrong is this service applied to this site: a rule that read correctly, deployed cleanly, returned no error and did nothing, plus two more found the same day that were a different species again.