Case study · Web application security

From Security Findings to Verified Fixes

An assessment identifies work to do. A retest checks what actually changed.

My role: Penetration tester, covering the initial assessment and follow-up testing.

An anonymised account of an engagement. Client details, dates, technical identifiers and exact finding counts have been omitted to protect confidentiality.

The question

A website needed a security assessment and a subsequent check of the changes made in response. My work was to identify weaknesses, document recommendations and revisit the application to assess remediation.

The useful question at the follow-up was specific: which earlier findings were resolved, which remained, and what else needed attention in the updated site?

What I examined

The assessment covered the website’s configuration and browser-facing controls. Areas of review included encrypted connections, software dependencies, response headers, cookie settings and unintended information exposure.

The reports brought together automated scanning and targeted inspection. Findings were documented with observations and recommended actions. A missing defensive setting and a demonstrated exploit are different kinds of evidence; this account does not treat them as interchangeable.

Returning to the findings

Follow-up testing compared the updated site with the earlier report. It recorded substantial progress: most of the original findings were marked resolved. Some remained open, and the retest identified additional issues requiring attention.

That distinction matters. A development change can address an earlier finding without resolving every related control. Testing the updated application also provides an opportunity to notice issues outside the original list.

The result

The retest produced a clearer record of completed remediation and outstanding work. The result was evidence of progress, alongside a remaining set of actions for the team responsible for the website.

My role was assessment and verification. This account does not claim that I implemented the fixes, that every issue was closed, or that the site was free from vulnerabilities.

What this work illustrates

A report is useful when someone can act on it. Following the findings through a retest makes that work more accountable: the team can distinguish a proposed fix from a change that has been checked, and can see where further investigation is still needed.