Website Security: What the Design Does Not Show
Appearance and access are different tests
A page can look finished while the functions behind it have not been tested properly. This applies whether the code was written manually, generated with AI or assembled from existing components.
OWASP’s web application guidance includes risks involving access control and security configuration. A visual review alone does not establish whether those controls work.
Test what each person is allowed to do
Work through the site as a public visitor, a customer and each relevant staff role. Check that a person cannot read or change somebody else’s information by using a different link or request. Hiding a button is not the same as enforcing permission on the server.
Keep secrets out of public assets
Credentials belong in controlled server configuration, not in downloadable scripts, demo data or screenshots. A private repository is not a reason to leave live credentials in a test report. When exposure is found, removing the text is only part of the response; the affected credential also needs to be handled.
Verify the actual enquiry and document paths
Confirm where a message is saved, who can access a document and what happens when a service fails. A success screen should correspond to a successful operation. Test backups and recovery with suitable test data rather than relying on the existence of a backup setting.
Make the checks part of delivery
NexOps treats the website and the functions behind it as one project. The agreed acceptance checks should include the journeys the business will depend on, not only the home page design.
