Updated: 22 October 2026.
I am cautious about calling a website secure without explaining what was checked. A public scan, an authenticated application review and a server investigation answer different questions.
The useful starting point is a defined scope: which applications, accounts, interfaces and environments are included, and which risks matter to the business?
For a shop, unauthorised changes to orders or prices may matter as much as the public homepage. For a membership service, access to another person’s records may be the central concern.
Start with what is exposed
I would inventory the public application, administrative interfaces, APIs and supporting services. I would review HTTPS behaviour, externally visible configuration and software components that need maintenance.
A public observation has limits. A version banner may be absent or misleading, and a vendor may backport a fix. I would verify patch status through the available administrative evidence rather than treat a fingerprint as a complete inventory.
Security headers belong in this review, but they cannot tell me whether a logged-in customer can read another customer’s invoice.
A useful website assessment combines several kinds of evidence and reports the boundaries of the checks performed.
flowchart TD A["Agreed scope and test accounts"] --> B["Public exposure review"] A --> C["Role and resource access tests"] A --> D["Sensitive workflow tests"] A --> E["Maintenance and recovery review"] B --> F["Reproducible findings and coverage limits"] C --> F D --> F E --> F F --> G["Remediate and retest"]
Test access using different roles
With explicit authorisation and suitable test accounts, I would build a small access matrix. What should an anonymous visitor, customer, staff member and administrator be able to do?
For each important action, I would test the server’s decision. Hiding a button is not an access control if the underlying request still succeeds.
In a fictional billing application, two customers might each have an invoice. The review should establish whether customer A can access customer B’s invoice through any supported interface. Production testing needs agreed boundaries so that security checks do not expose real records or disrupt service.
Examine workflows as well as inputs
Login, password recovery, account changes, uploads and payment-related workflows deserve attention because they cross sensitive boundaries.
I would ask whether steps can be skipped, requests replayed or values changed outside the intended sequence. A form can reject malicious-looking text while still allowing a business action the user should never be permitted to perform.
For uploads, I would examine where files are stored, how they are served and who can retrieve them. A filename extension check alone does not explain the whole control.
Include maintenance and recovery
The website depends on hosting accounts, deployment credentials, dependencies, backups and people who can change them. I would review those responsibilities alongside the application.
Are unused plugins and accounts removed? Are important actions logged without recording secrets? Can the team restore the service, and has it tested that procedure? Who receives a security alert, and what happens when that person is unavailable?
These questions do not all require a penetration test, but leaving them unanswered creates gaps in the overall assessment.
Report findings with their boundaries
For each issue, I want a reproducible observation, the conditions required, the likely impact and a practical correction. The report should also identify what was not tested and what needs verification after remediation.
“No issue found in the agreed checks” is a meaningful result. It should not become “no vulnerability exists.” My aim is to give the owner a clear account of the evidence and the next decisions, rather than a reassuring badge with an undefined scope.
