An AI-built website security checklist before launch.

1. Write down what the website actually does

Before asking whether your AI-built website is secure, describe what it needs to protect. List the public pages, private areas, APIs, payment integrations, administrative functions, and information the business stores. Include who owns each system.

This gives a reviewer a starting point and helps prevent a small initial check being mistaken for a complete audit. Ask for the scope and exclusions in writing. The OWASP Web Security Testing Guide provides a broader reference for planning web application testing.

2. Separate logging in from having permission

A login proves an identity; it does not automatically establish what that identity should be allowed to access. Write down what a visitor, ordinary user, and administrator may view or change. If the application serves several organizations, define the boundary between them too.

Ask the reviewer to examine the server’s enforcement of those rules. Hiding a button in the browser does not enforce authorization. OWASP’s authorization guidance recommends checking permissions on every request and denying access by default. Use designated test accounts and test data within an authorized scope.

3. Know where credentials and sensitive data live

Identify API credentials, database access details, service tokens, and any privileged keys used by the project. A credential that must remain secret should not be shipped to visitors in browser code or committed to a public repository. Public identifiers are different from credentials that grant privileged access.

If a secret has already been exposed, removing it from the current page is not enough: revoke or rotate it as appropriate and examine its use. OWASP’s secrets management guidance covers storage, access control, rotation, and incident response.

4. Review what the server accepts

A browser form may reject an invalid value while the server accepts it. Review how the backend handles unexpected values, missing fields, uploads, and requests outside the normal interface. The relevant behavior depends on the application and the agreed test scope.

OWASP’s input validation guidance calls for server-side validation because client-side checks can be bypassed. Validation is one control; it does not replace authorization, safe data handling, or other protections.

5. Ask what was tested—and what was left out

A security review should leave you with an understandable record. Ask for the features checked, the relevant account roles, any confirmed findings, and practical next steps. If a problem is fixed, agree whether retesting is included or separately scoped.

Keep a copy of those boundaries when the site changes. Adding a new upload flow or administrative feature is a reason to revisit the relevant checks. A previous review applies to the version and scope assessed, not every future change.

Ready for a focused first look? See VEYRSEC’s website check pricing, or read where AI fits into penetration testing. Testing starts only after scope and permission are agreed.