Ask better questions.A checklist is
not an audit.

01 / FIELD NOTESFive areas to ask about

The organizer above records your answers for this page only. “Evidence supplied” means you selected that answer; it is not an assessment performed by the website. There is no score, pass badge, external scan, or stored report.

1. Is the connection protected?

Check the actual address and any browser warnings, particularly on pages that accept logins or form data. Do not rely on a particular padlock icon: browsers present connection information differently.

Technical clarification: HTTPS protects the connection in transit. It does not prove that the site handles input correctly, stores credentials safely, or has up-to-date dependencies. That distinction follows OWASP's TLS guidance.

2. What slows down repeated login attempts?

Ask how the application limits repeated failures and where that behavior is enforced. A login screen looking normal on public Wi-Fi does not answer that question.

You do not need to guess passwords repeatedly against a live site to investigate. Ask the maintainer for the relevant configuration and a controlled test. The useful evidence is a configured control and a test of what it actually blocks.

3. How are invalid form submissions handled?

With permission, use a staging environment or agreed test window to try empty required fields and harmless invalid values. Avoid sending test junk into a real customer's inbox or payment workflow.

A form should explain what needs fixing without losing useful answers. A polished response is still not proof that the backend is secure.

Technical clarification: client-side validation can be bypassed. Server-side validation is necessary, and validation alone is not the primary defense against SQL injection. See OWASP's input-validation guidance. The Atlas remediation article examines a database query separately.

4. Can access be managed person by person?

Ask whether each staff member has an account, how access is removed, and which actions are recorded. Individual access and useful activity history solve related but different problems.

An audit log also needs a failure policy. In the documented Southside example, a content change can succeed even if a separate logging attempt fails. An “audit log” label is not a promise that every change is captured.

5. Who owns maintenance?

Ask when dependencies or plugins were last reviewed, who applies updates, and how changes are tested. A redesign date does not answer those questions.

The original guide focused on forgotten plugin updates. The broader ownership question is just as useful: who notices a security advisory, who decides what to do, and who verifies that the site still works afterward?

02 / FIELD NOTESWhat the checklist cannot tell you

The original article names database input handling, secret storage, and known dependency vulnerabilities as areas needing technical inspection. Keep them there.

Those checks require the actual code, configuration, and running system. A browser-only conversation cannot establish them, and a scanner result is one piece of evidence rather than a substitute for understanding the application.

03 / FIELD NOTESTurn uncertainty into a next step

An unanswered question is not proof that the site is compromised. It is a place to ask for evidence and assign an owner.

Use the organizer to separate what you know from what still needs checking. A useful handoff is specific: “Please show how this form is validated on the server,” or “Please confirm how this account is revoked.” That gives the next review a clear starting point without pretending a checklist has done the review already.